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PREFACE 

This addendum to the RSTS-11 System Manager's Guide, order 
number DEC-11-ORSMA-B-DN2, describes the system generation proce- 
dures for version V04B-17 of RSTS-11. Also included is information 
concerning a new initialization option (PATCH) and new system pro- 
grams and SYS system function calls. All known deficiencies in 
Version 4A-12 have been corrected in Version 4B-17. 

To update the subject manual, perform the following steps. 

Replace the old Preface and CONTENTS pages with new CONTENTS 
pages. 

Replace the old Chapter 2 with the new Chapter 2. 

Replace pages 3-7, 3-8, 3-9, and 3-10 with new pages 3-7, 3-8, 
3-9, 3-9.1, 3-9.2, 3-9.3 and 3-10. 

Replace old pages 4-17 and 4-18 with new pages 4-17, 4-18, 
4-18.1 and 4-18.2. 

Replace old pages 5-1 through 5-8 with new pages 5-1 through 
5-8.1. 

Replace old page 5-39 with new pages 5-39 through 5-49. 

Remove Chapter 7. 

Replace old Appendix A with new Appendix A. 

Replace old Appendix C with new Appendix C. 

Replace old Appendix E with new Appendix E. 

Remove Appendix G. 

Replace the old HOW TO OBTAIN SOFTWARE INFORMATION page with the 
new one. 

Replace the old READER'S COMMENTS page with the Addendum 
READER'S COMMENTS page. 

Place the Addendum Title page behind the current title page. 

Place this Preface page behind the new CONTENTS pages and annotate 
the current CONTENTS page with the following: Updated by Addendum 
DEC-11-ORSMA-B-DN2 dated February 1975. 
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CHAPTER 1 
INTRODUCTION TO RSTS-11 SYSTEM MANAGEMENT 

1.1 OVERVIEW OF SYSTEM STRUCTURE 

The RSTS-11 Resource Time Sharing System is comprised of PDP-11 
hardware units and system software components which allow multiple 
users simultaneous, time-shared access to the full computational and 
data-processing power of the BASIC-PLUS language, to an efficient 
and versatile mass-storage structure, and to a shared set of chosen 
peripheral resources. 

1.1.1 System Hardware 

The heart of the RSTS-11 hardware is the PDP-11 Central Proc- 
essor Unit (CPU) , equipped with a time-clock. The interrupt, stack, 
general-registers, and Unibus structures ideally equip the PDP-11 
CPU for governing and controlling the time-shared processing. 

A system disk (RF11, RKll, or possibly an RK11 in combination 
with an RC11) provides the necessary mass-storage for the system, and 
can be augmented by additional disk structures . 

Local terminals and dataphone ports to remote terminals open 
the system interactively to as many as 16 simultaneous users. These 
terminals may be standard Teletypes 1 , DECwriters, or video-type ter- 
minals (VT05) . Moreover, when these terminals are not logged into the 
system they are available to other users as programmable peripheral 
devices . 

Finally, the power of the RSTS-11 system hardware can be com- 
plemented by a full set of shared peripheral resources, such as line 
printer, card reader, magnetic tape, DECtape, and high-speed paper 
tape. 



teletype is a registered trademark of the Teletype Corporation. 
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A typical small system, capable of being expanded by the 
addition of Teletypes or other terminals, is as follows: 

PDP-11 System Building Block (PDP-11 computer) 
28K of 900 ns read/write core memory 
Dual DECtape transport and Control (TU56) 
256K DECdisk and Control (RS11) 
Real-Time Clock (Line Frequency) (KW11L) 
Hardware Bootstrap Loader 
Cabinets and Mounting Hardware 

1.1.2 System Software 

RSTS-11 system software exists at two levels. The primary 
level exists in PDP-11 assembly language code and governs the most 
essential and frequent operations of the system; once the system is 
generated> this code is "frozen" and not altered thereafter. The 
secondary level of RSTS-11 software consists of system library 
programs written in the BASIC -PLUS language and alterable at any 
time; these programs are called into execution either by the primary 
system itself or by individual users to perform infrequent functions 
or functions which can be designed and implemented by the system 
manager. 

1.1.2.1 Primary System Software Elements, Assembly Language Programs 

The PDP-11 assembly language elements of the RSTS-11 system 
are comprised of many distinct modules but can, in general, be 
classified into generic groups as follows: 

(1) permanently core-resident elements: 

(a) interrupt and trap vectors, 

(b) system buffers, large (256 words) and small 
(16 words) , 

(c) system- information data-cells and tables, 

(d) disk and I/O device drivers, 

(e) resident file processor, 

(f) general executive routines, 

(g) on-line Editor (builds text of program lines) , 

(h) incremental Compiler (converts BASIC lines into 
shorter intermediate code stored in the user 
j c - cirea, , 

(i) Run-Time System (interpretatively executes inter- 
mediate code from user Bre-?. ) - 
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(2) temporarily core-resident elements: 

(j) system initialization code (executed at start-up 
time and immediately overlaid thereafter by 
user job areas) . 

(3) disk-resident elements: (loaded into and executed from 
an in-core buffer when needed) : 

(k) file-processor routines, 

(1) user-core allocation and clean-up routines, 

(m) DECtape processor. 

1.1.2.2 Secondary System Software Elements, System Library Programs 

The system library programs are actually run in the same manner 
as a user program; that is, they are executed from the user job area 
like any other BASIC-PLUS program. System library programs remain, how- 
ever, under the control of the system manager; and, since they can make 
extensive use of privileged program status and SYS functions, they 
exercise wide control over the system. The primary software elements 
call upon some of these programs to augment their own functions, the 
system manager will use others to monitor and regulate system usage, 
and ordinary users can call upon others to perform common utility 
functions. 

1.1.3 System Disk Structures 

RSTS-11 V4A contains a logical public disk structure, which 
consists of a system disk (RFll-type or RKll/RCll- types) and optionally 
additional public disk packs . All public disks must be on-line when- 
ever the system is running and are accessible to all users; they can 
be logically distinguished from each other under program control. 
Elements of the system software are stored on the system disk, in- 
cluding a core image 1 of the core-resident system elements. The 
system disk is also used as a swapping device for temporary storage 
of active user jobs until it is their turn to run. Additional space 
on the system disk as well as all space on other public disks is 
available for general storage of user programs and data files. 



1 Core image is the executable machine code as it would be in 
core prior to START. 
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In addition to the public disk structure, RSTS-11 also accom- 
modates private disk structures, i.e. disk packs to which access is 
granted only to a defined set of users for storage of programs and 
data files. Private packs can be mounted or dismounted on-line. 

1.1.4 General Concepts of System Control 

Users active at terminals can be operating either in edit mode 
or in run mode . 

When first logged into the system, the user is in edit mode 
and returns to edit mode at the completion of any program execution 
or whenever he types CTRL/C. In edit mode, the system examines each 
ASCII line entered by the user and determines whether that line is a 
system command, an immediate-mode statement, or a program statement. 
System commands are executed immediately. Immediate-mode statements 
are first translated into an intermediate code, which is placed into 
the user's job area and then executed immediately by the Run-Time 
System. Program statements are stored in their ASCII form in a 
temporary disk file (created by the system with a name of the form 
TEMPnn.TMP under the user's account) and are also compiled, line by 
line, into their intermediate code representations and stored in the 
user job area. The user job area is initialized to a size of 2K 
words but can grow, as necessary, in IK increments to a maximum size 
of 6K (in 24K systems) or 8K (in 28K systems) . Program statements 
are not executed in edit mode, but the program being created can be 
changed, a copy of the compiled program can be transferred to disk 
storage (as a -BAC file), or a copy of the ASCII source .program can 
be saved on disk storage (as a .BAS file) or on an external medium. 

A user changes from edit mode to run mode when he types the RUN 
command or the CHAIN immediate mode statement. In run mode, the Run- 
Time System interpretatively executes the intermediate code stored 
in the user job area. Following program execution, the user is re- 
turned to edit mode. The user can interrupt the Run-Time System 
by typing CTRL/C; this also returns the user to edit mode. 
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The system allows user jobs to run (in either edit or run mode) 
one at a time. A user job will run until it either enters an I/O-wait 
condition or exhausts the time quantum which the system has assigned 
to it. At that point the system Scheduler, in round-robin fashion, 
finds the next job that is ready to run and begins that job. Mean- 
while the interrupt-driven I/O handlers are processing the requested 
data transfers (for all devices except disks and magnetic tape, inter- 
mediate system buffers are used for the peripheral transfers) and 
upon completion of a transfer, mark the job which requested the trans- 
fer as again ready to run. In the process of round-robin scanning, 
the Scheduler will see that the marked job is ready to run again and 
re-starts it from the point at which execution was last suspended. 

The system keeps as many jobs in core as possible, but when more 
core is required than is available, the system temporarily moves some 
jobs out of core and stores them in the disk file SWAP. SYS. When it 
is again their turn to run, these jobs are swapped back into core 
from the' SWAP. SYS file. Thus, jobs waiting for keyboard input and 
jobs waiting for device I/O completion will likely be stored on the 
SWAP. SYS file, while jobs currently running and jobs involved in 
current disk or magnetic tape transfers must necessarily be in core. 

As the system processes each job, it maintains accounting infor- 
mation (in core) concerning that job. When the job logs out this 
information is used to update the accounting information stored on 
the disk for that account. 

1.2 SYSTEM GENERATION 

RSTS-11 software is supplied in a form which allows it to be 
configured easily to any standard RSTS-11 hardware configuration. It 
also allows choices concerning optional software features which may 
be included in the system for processing power or may be excluded from 
the system for core economy. The system manager is advised, there- 
fore, to study Chapter 2 of this manual in order to become thoroughly 
familiar with the software configuration options that are open to 
him; he can then select those features and parameters which best suit 
his applications requirements. Following the directions in Chapter 2, 
the system manager can create his initial RSTS-11 system and can 
re-configure and re-create it to meet expanding or altered needs. 
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1.3 SYSTEM BACK-UP 

Once a system has been created, extreme care should be taken to 
maintain back-up material for it. The supplied RSTS-11 kit itself 
should be stored in a safe place. Along with the supplied kit, the 
system CIL DECtape, which is created at system-generation time, 
should be stored; this DECtape contains the configured system soft- 
ware and makes it possible to re-load that software onto the disk if 
this should become necessary. The ROLLIN program, which is supplied 
in the RSTS-11 kit (see Chapter 6), enables" the system manager to 
make image-mode copies of any disk for back-up purposes . 

1.4 SYSTEM MANAGEMENT 

The RSTS-11 system manager (and all other users holding privileged 
accounts) is provided with many powers and facilities for controlling 
the RSTS-11 system. 

The system manager assigns the system account numbers and pass- 
words and thereby determines who has privileged access to the system 
and who has ordinary access. 

By retaining a privileged account for himself, the system man- 
ager can run the special system library programs which allow him to 
monitor and reset the system accounting information (with MONEY) , 
to regulate accounts (with REACT) , and to govern the use of the 
system facilities (with UTILTY) ; and he likewise by-passes any 
file protection restrictions when he runs any program. The system 
manager can expand the system library to create his own utility 
programs to accomplish functions peculiar to the needs of his in- 
stallation. He has access to a wide selection of SYS functions (see 
Chapter 4) , privileged and otherwise, to facilitate such programming. 
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CHAPTER 2 

RSTS-11 SYSTEM GENERATION 

This chapter describes the procedures to generate Version V04B-17 
RSTS system code from software distributed on 7-track and 9-track 
magtape, DECtape, and RK disk cartridge (DECpack) . Section 2.1 
presents an overview of the system generation process and contains 
comments concerning the media on which DIGITAL distributes the software. 

Section 2.2 contains the bootstrap and SYSLOD procedures reguired 
for magtape and DECtape software. Section 2.3 describes the bootstrap 
and copy procedures for disk cartridge software. Procedures to start 
the system generation batch command file are in Section 2.4. Examples 
and guidelines to answering configuration questions are in Sections 
2.5, 2.6, and 2.7 respectively. 

2.1 SYSTEM GENERATION OVERVIEW 

The process for generating the RSTS system code consists of the 
following general steps. 

a) If the software is on magnetic tape, bootstrap a tape to 
load the stand alone program SYSLOD and transfer the system 
generation monitor to a disk using SYSLOD. If the software 
is on disk cartridge, bootstrap the system generation disk 
to load the system generation monitor. 

b) Log into the system generation monitor and initiate execution 
of the batch command file. 

c) Answer configuration questions printed during the system 
generation dialogue. 

d) Follow the instructions printed by the system generation 
monitor and mount and dismount tapes and disks as required. 

After the user creates the RSTS system code, he must proceed to 
Sections 2.10 and 2.11 to build the RSTS system disk and system library 
files. 
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The user performs the system generation procedure using the DOS/ 
BATCH V09-20 monitor as the system generation monitor. If the DEC- 
supplied software is on magtape or DECtape, the user must load this 
monitor onto an RF11 or RKll disk using the stand alone program 
SYSLOD. If the DEC-supplied software is on disk cartridge, the user 
need only bootstrap the cartridge to load the system generation 
monitor. (In this document, the disk on which the system generation 
monitor resides is referred to as the system generation disk. Such 
nomenclature differentiates the disk in question from the disk on 
which the user eventually builds the RSTS public file structure and 
which is referred to as the RSTS system disk.) 

The procedures for magtape or DECtape distribution software in- 
volve transferring files to the system generation disk. After loading 
the system generation monitor onto a disk, the user must transfer one 
batch command file from the tape to the disk. The user then initiates 
execution of the batch commands which transfer all required system 
generation programs (MACRO, LINK, CILUS, EDIT, PIP, and SYSLOD) from 
tape to disk without further interaction. 

The procedures for disk cartridge distribution software are 
similar to those for tape except that none of the file transfer 
operations described are necessary. However, it is advisable that 
the user copy the disk cartridges containing the system generation 
and system library programs and use the copies instead of the originals 
to generate the system. To copy the disk cartridges, the user runs 
ROLLIN as described in Section 2.3.2 of this guide. To begin system 
generation, the user bootstraps the copy of the system generation 
disk cartridge, answers the system generation monitor DIALOGUE 
questions, and types one command which initiates execution of the 
batch command file. Commands in the batch file delete any old RSTS 
system which possibly exists from a prior system generation. 

After the system generation monitor transfers all files from 
tape or deletes files from the disk cartridge, it executes a command 
in the batch file which runs the system generation program SYSGEN. 
The program prints approximately 45 hardware and software configuration 
questions and creates two files based on the answers typed in response 
to each question. The answers must accurately reflect the hardware 
configuration on which RSTS will run and the software options desired. 
Durir.q the configuration dialogue with the user, SYSGEN creates the 
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configuration file CF.MAC and a second batch command file SYSGEN.BAT, 
which are later used to create the RSTS system code tailored to local 
installation requirements. 

After the user answers all the configuration questions, the 
system generation monitor executes the second batch command file. 
The monitor conditionally assembles the SY module (system tables) , 
the DK module (disk drivers) , and the TT module (terminal service) 
using the configuration file created during the SYSGEN dialogue. 

During execution of the second batch command file, the system 
generation monitor prints instructions for the user to mount appro- 
priate tapes or disks as each is required. The system generation 
monitor next links the monitor code, and overlay code (OV) and copies 
files from tape as needed. 

The final step in the system generation process creates a linked 
core image library (LICIL) of the RSTS system from the load modules 
created by the linking process. For magtape and DECtape software, the 
step includes writing the LICIL, system load map, batch and config- 
uration files, and SYSLOD program to a scratch tape. For disk 
cartridge software, the LICIL is created and remains on the system 
generation disk. 

During the final step for magtape and DECtape software, the 
monitor prints a message telling the user the exact command to type 
to write the contiguous core image library, or CIL, onto the RSTS 
system disk. The batch command file terminates by loading SYSLOD 
into memory. The user can type the exact command to SYSLOD and write 
the CIL to the RSTS system disk or, at some later time, can bootstrap 
the tape to load SYSLOD into memory. After writing the CIL to the 
RSTS system disk, SYSLOD automatically bootstraps the device to load 
the RSTS initialization code into memory. 

During the final step for disk cartridge software, the system 
generation monitor prints a message telling the user to mount and 
write enable the RSTS system disk. When ready, the user types a 
command to continue executing the batch file which runs CILUS to 
write the CIL onto the RSTS system disk without further user action. 
If the RSTS system disk is an RFll disk, the batch command file termi- 
nates by bootstrapping that device. If the RSTS system disk is an 
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RK disk, the system generation monitor prints a message telling the 
user to move the disk to RK unit and to bootstrap it by the hardware 
loader to load the RSTS initialization code. 

The RSTS Core Image Library contains the system initialization 
code, the monitox , the BASIC-PLUS Run Time System, overlay code, 
error messages, and, optionally, the stand alone programs ROLLIN and 
DSKINT. When the RSTS system disk is bootstrapped, the initialization 
code is loaded into memory. The user must install necessary patches 
(PATCH option) , create the system files (REFRESH option) , and begin 
time sharing (START option) . 

2.2 MAGTAPE AND DECTAPE PROCEDURES 

Magtape and DECtape procedures differ in the bootstrap procedures 
required and in the device designators used in several keyboard 
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2.2.1 Magtape Bootstrap Procedure 

Bootstrapping a magtape involves using the central processor unit 
(CPU) console switches and the MRll-DB Bulk Storage Bootstrap Loader. 
If the MRll-DB is not on the system, the user must deposit a loading 
routine manually from the console switch register. This action is 
necessary since the BM792-YB hardware loader cannot bootstrap a magtape. 

The CPU console switches are described in Chapter 8 of the 
PDP-11/45 Processor Handbook and the PDP-11/40 Processor Handbook 
and in Chapter 7 (Part I) of the PDP-11/20 Processor Handbook . Use 
of the magtape transport is described in Section 5.6 of the RSTS-11 
System User's Guide . 

To bootstrap the magtape, perform the following steps. 

Move the CPU Console ENABLE/HALT Switch to its HALT 
position. 

Mount the magnetic tape reel labelled DEC-11-0RTBB-A-MC7 
or -MC9 (SYSTEM GENERATION AND LIBRARY TAPE) on unit 
with the write enable ring removed. 

Ensure that the tape is at its load point. (The LD PT 
indicator comes on.) The computer does not bootstrap the 

device unless the tape is at its load point. 
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Set the ON-LINE/OFF LINE switch on the tape unit to 
ON-LINE and ensure that the RDY indicator is lit. 

Ensure that the console terminal is on line. 

If the MRll-DB loader is on the system, proceed to 
Section 2.2.1.1. If the system configuration does not 
include the MRll-DB loader, go to Section 2.2.1.2. 

2.2.1.1 MRll-DB Procedure - If the MRll-DB is on the system, perform 
the following steps. 

Set the CPU console Switch Register to 773136. 

Depress the CPU console LOAD ADRS switch. 

Move the CPU console ENABLE/HALT switch to its ENABLE 
• position. 

Depress the CPU console START switch. 

Proceed to Section 2.2.3 to transfer the system genera- 
tion monitor from tape to disk. 

2.2.1.2 Systems Without the MRll-DB Loader - If the system configura- 
tion does not include the MRll-DB hardware loader, the user must manu- 
ally enter the following load routine using the CPU Console Switch 
Register and DEP Switch. To load the routine, perform the following 
steps. 

Move the CPU Console ENABLE/HALT switch to its HALT 
position. 

Set the Switch Register to 010000. 

Depress the CPU LOAD ADRS switch. 

Load the following contents into memory using the 
Switch Register and DEP switch. 

Address Contents 

010000 012100 

010002 172524 

010004 005310 

010006 012740 

010010 060011 

010012 105710 

010014 100376 

010016 005710 

010020 100767 

010022 012710 

010024 060003 

010026 105710 

010030 10037 6 

010032 005710 

010034 100777 

010036 005007 
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Set the Console Switch Register to 010000. 

Depress the CPU Console LOAD ADRS switch. 

Depress the CPU Console START switch. 

Proceed to Section 2.2.3 to transfer the system genera- 
tion monitor from tape to the disk. 

2.2.2 DECtape Procedures 

Bootstrapping a DECtape involves using the central processing 
unit (CPU) console switches and either the MRll-DB or BM792-YB hard- 
ware bootstrap loader. The CPU switches are described in Chapter 8 
of either the PDP-11/45 Processor Handbook or the PDP-11/40 Processor 
Handbook and in Chapter 7 (Part I) of the PDP-11/20 Processor Hand - 
book . Use of the DECtape transport is described in Section 5.5 of 
the RSTS-11 System User's Guide . 

To bootstrap the DECtape, perform the following steps. 

Move the CPU Console ENABLE/HALT switch to its HALT 
position. 

Mount the DECtape reel labelled DEC-11-ORDBA-A-UB 
(DOS MONITOR) on unit 0. 

On DECtape unit 0, set the REMOTE/OFF/LOCAL switch to 
REMOTE and the WRITE ENABLE/WRITE LOCK switch to WRITE 
LOCK. 

Ensure that the console terminal is on line. 

Proceed to Section 2.2.2.1 if the MRll-DB is on the 
system. Otherwise, follow the procedures in Sec- 
tion 2.2.2.2. 

2.2.2.1 MRll-DB Procedures - If the MRll-DB Bootstrap Loader is on 
the system, 

Move the CPU Console ENABLE/HALT switch to its ENABLE 
position. 

Set the CPU Console Switch Register to 773120. 

Depress the CPU Console LOAD ADRS switch. 

Depress the CPU Console START switch. 

Proceed to Section 2.2.3 to transfer the system genera- 
tion monitor from tape to the disk. 
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2.2.2.2 BM792-YB Procedures - If the BM792-YB Bootstrap Loader is on 
the system, 

Set the CPU Console Switch Register to 773100. 

Depress the CPU Console LOAD ADRS switch. 

Move the CPU Console ENABLE/HALT switch to its ENABLE 
position. 

Set the CPU Console Switch Register to 777344. 

Depress the CPU Console START switch. 

Proceed to Section 2.2.3 to transfer the system genera- 
tion monitor from tape to the disk. 

2.2.3 Loading the System Generation Monitor From Tape 

After the user follows the magtape or DECtape bootstrap procedures 
described in Sections 2.2.1 and 2.2.2, the computer reads unit and 
loads SYSLOD into memory. SYSLOD prints its identification line 
followed by the first in a series of queries as follows. 

SYSLOD V07-02A 
CONSOLE FILL COUNT= 

If SYSLOD does not print its identification and the processor 
halts, a parity error possibly was detected in reading the tape. 
Retry the entire procedure, including rewinding the tape to its load 
point. (When using magtape on systems without the MR11-DB hardware 
loader, verify the accuracy of the loading routine by use of the CPU 
Console EXAM switch before retrying the procedure. Use the DEP switch 
and the CPU Console Switch Register to correct any errors. If SYSLOD 
fails to identify itself, it will be necessary to obtain a new magtape 
reel. ) 

2.2.3.1 Answering the SYSLOD Questions - When SYSLOD runs, perform 
the following steps. 

If the system generation disk is either an RK03 or 
RK05 cartridge, mount it on drive unit 0. 

Ensure that the system generation disk is on line, 
write enabled, and ready before proceeding. (After 
the DIALOGUE query is answered, SYSLOD does not 
recognize any devices previously not ready.) 
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Type the RETURN key in response to the CONSOLE FILL COUNT question 
and proceed as follows: 

SYSLOD V07-2A 

CONSOLE FILL COUNT= (Type RETURN key.) 

DATE: l^-JUL-?^ (Type in dd-mmm-yy format.) 

DIALOGUE? (Type RETURN key.) 

£ 

Type the current date in the standard dd-mmm-yy format and type 
the RETURN key in response to the DIALOGUE query. 

SYSLOD indicates that it is ready to accept a command string by 
printing the # character. A single command string is necessary to 
format the disk, to check for .bad blocks, and to transfer the system 
generation monitor to the disk. Use the following format for the 
SYSLOD command string. l 

#xx : MONLIB . CIL/FO/CO : 2/H0/B0<yy : MONLIB . LCL 
where : 

xx is DK for an RKJ35 or RK03 disk cartridge 
DF for an RF-type disk. 

NOTE 

The /FO switch is not necessary 
for RF-type disks. 

yy is DTJ3 if DECtape software is used, or 

MTJZf if either 7- or 9-track magtape software is used. 

The /FO switch in the SYSLOD command causes a removable disk to 
>>p F/~i >-TTia +-+* esri "pt^o /^Q ; 2 e witch wri**e e two patterns on each block of 
the disk to ensure that no bad blocks are used. The /HO switch causes 
SYSLOD to place a pointer to the CIL in the bootstrap record. The /BO 
switch causes SYSLOD to bootstrap the device upon completing the trans- 
fer. 

The entire process takes between 5 and 15 minutes depending upon 
the size and type of disk. If SYSLOD prints any error messages, con- 



'On an LA30(S) DECwriter and a VT05 alphanumeric display terminal, it 

may be necessary to use the SHIFT key while typing alphabetic charac- 

-i-o-v-o i -n r^vAc-i-r- f- r-* iTic-i'vp 4- V* ^ -f- * -i -p, i~i n T ^pcp nhqvsnf ore 3.Te transmitted 
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suit Appendix C for the meaning and possible steps for recovery. Upon 
completing the transfer, SYSLOD prints the following messages. 

SYSLOD COMPLETE 

ANSWER WITH CARRET OR '_V CARRET: -IS YOUR LINE FREQUENCY 50 HERTZ? 
DO YOU WANT TO DISABLE DIALOGUE FOREVER? NO 
DOS/BATCH V09-20 
DATE : 

Type the RETURN key (CARRET for carriage return) if the line 
frequency of the power used to run the PDP-11 is 60 Hertz. Otherwise, 
type Y and the RETURN key to indicate 50 Hertz . 

SYSLOD then prints a question asking if the user wants to disable 
the dialogue forever. The system generation monitor begins with a 
dialogue similar to that used by SYSLOD. It is possible to disable 
this dialogue at this time by typing Y followed by the RETURN key. 
For RSTS system generation purposes, type NO so that the dialogue is 
not disabled. Proceed to Section 2.4.1 for instructions on answering 
the system generation monitor dialogue. 

2.3 DISK CARTRIDGE PROCEDURES 

Disk cartridge procedures involve bootstrapping the device and 
copying the original distribution cartridges using the stand alone 
program ROLLIN. 

To prevent possible destruction of the system generation and 
system library disk cartridges, it is advisable to copy the car- 
tridges and use the copies for system generations. The cartridges 
are created on properly aligned drives. Since drive alignment 
drifts slightly in shipping and with age, problems possibly occur 
at a user site. If the user cannot copy the cartridges, DIGITAL 
Field Service must check the drive alignment before system genera- 
tion can continue. The stand alone program ROLLIN is included on 
the system generation disk cartridge to facilitate the copy opera- 
tion. 

2.3.1 Disk Cartridge Bootstrap 

Bootstrapping a disk cartridge involves using the central pro- 
cessor unit (CPU) console switches and either the MR11-DB or BM792-YB 
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hardware loader. The CPU console switches are described in Chapter 8 
of the PDP-11/4 5 Processor Handbook and the PDP-11/40 Processor Hand - 
book and in Chapter 7 (Part I) of the PDP-11/20 Processor Handbook . 

To bootstrap the cartridge, perform the following steps. 

Physically mount the cartridge labelled DEC-11-ORDPB-A-HC 
(SYSTEM GENERATION) in the RK03 or RK05 unit . 

Ensure that the RDY light is on. 

If the cartridge is not yet copied, ensure that the 
WR PROT light is on. (This condition write protects 
the disk.) If the copying is complete, ensure that 
the WR PROT light is off. On an RK05 drive, depress- 
ing the WR PROT switch alternately turns the WR PROT 
light on and off. 

Ensure that the console terminal is on line. 

Move the CPU Console HALT/ENABLE switch to its HALT 
position and back to its ENABLE position. 

If the MR11-DB Bulk storage bootstrap loader is on 
the system, go to Section 2.3.1.1. Otherwise, go to 
Section 2.3.1.2. 

2.3.1.1 MR11-DB Procedure - If the MRll-DB is on the system perform 
the following steps. 

Set the CPU Switch Register to 773110. 

Depress the CPU LOAD ADRS switch. 

Depress the CPU START switch. 

Proceed to Section 2.3.1.3. 

2.3.1.2 BM792-YB Procedure - If the BM7 92-YB Hardware Loader is on 
the system, perform the following steps. 

Set the CPU Switch Register to 77 3100. 
Depress the CPU LOAD ADRS switch. 
Set the CPU Switch Register to 777406. 
Depress the CPU START switch. 
Proceed to Section 2.3.1.3. 
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2.3.1.3 Monitor Identification - The system reads the disk and loads 
the system generation monitor which prints the following lines. 

DOS/BATCH V09-20 
DATE: 

If the monitor fails to identify itself, retry the entire proce- 
dure, and carefully check the switch register data. After the monitor 
prints its identifying lines, proceed to Section 2.3.2 to copy the 
system generation and system library cartridges or proceed to Sec- 
tion 2.4 to start system generation. 

2.3.2 Copying the Disk Cartridges Using ROLLIN 

To copy the disk cartridges, perform the following steps. 

Mount a new disk cartridge on drive unit 1. 

Ensure that the RDY light comes on and that the WR PROT 
light for unit 1 is off. 

Ensure that the WR PROT light for unit is on. The 
original disk must be write protected to prevent in- 
advertent destruction. 

Continue the dialogue in the following manner. 

DOS/BATCH V09-20 

DATE : ll-JUL-74 (Type in dd-mmm-yy format.) 

TIME : 06:51 (Type in hh:mm format.) 

DIALOGUE? (Type the RETURN key) 

When the monitor prints the $ character, type the LO 1,1 command. 
The monitor prints the current date and time followed by the $ charac- 
ter. 

$L0 1,1 (Terminate with RETURN key.) 

DATE: ll-JUL-7 1 * 
TIME: 0b:~52 
I 

The user must run the CILUS program to load ROLLIN. Type the 
RUN CILUS command as shown. 

$RUN CILUS (Terminate with RETURN key.) 

CILUS V08-06A 



f 
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CILUS runs and prints its header line followed by the # character. 
Type the command shown to run ROLLIN and subsequently to copy unit 
to unit 1. 

£ROLLIN.CIL/BO (Terminate with RETURN key.) 

ROLLIN V07 

#DK1:/FO<DK0:/VE (Terminate with RETURN key.) 

ROLLIN prints messages signalling the start and end of the format 
pass and the start of the verification pass. If no errors are encoun- 
tered, ROLLIN prints the # character again as shown below. 

STARTING RK FORMAT PASS 
END RK FORMAT PASS 
STARTING VERIFICATION PASS 



If any errors are encountered, ROLLIN prints appropriate messages 
and the # character. The user must contact a Field Service representa- 
tive to align the drive. If ROLLIN does not print any error messages, 
the user can continue according to the following steps. 

Move the LOAD/RUN switch to its LOAD position on both 
units and 1. 

When the LOAD light comes on, remove the cartridges 
from their respective drives. 

Label the copied cartridge in such manner as SYSTEM 
GENERATION COPY. Store the original in a safe place. 

Mount the disk cartridge labelled DEC-11-ORPTB- A-HA 
(SYSTEM LIBRARY) in unit 0. Ensure that the WR PROT 
light is on. 

Mount a second new cartridge in unit 1. Ensure that 
the RDY light comes on and that the WR PROT light for 
unit 1 is off. Ensure that the WR PROT light for unit 
is on. The original disk on unit must be write 
protected. 

Since ROLLIN is still waiting, type the following command in 
response to the # character. 

#DK1:/FO<DK0:/VE 
STARTING RK FORMAT PASS 

END RK FORMAT PASS 

STARTING RK VERIFICATIO N PASS 
I 

r eux ucax v ± ■* i ^ 
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If any errors are encountered, ROLLIN prints appropriate messages 
and the # character. The user must contact a Field Service representa- 
tive to align the drive. If ROLLIN does not print any error messages, 
the user can continue according to the following steps. 

Move the LOAD/RUN switch to its LOAD position on both 
units and 1. 

When the LOAD light comes on, remove the cartridges 
from their respective drives. 

Label the copied cartridge in such manner as SYSTEM 
LIBRARY COPY. Store the original system library 
cartridge with the original system generation car- 
tridge. 

Mount the copied system generation disk in unit and 
move the LOAD/RUN switch to its RUN position. Ensure 
that the RDY light comes on and that the WR PROT light 
is off. (The disk must be write enabled.) 

Bootstrap unit by typing the following command to ROLLIN. 

#/B0 : DK 

DOS/BATCH V09-20 
DATE: 



Proceed to Section 2.4.1 to start the system generation monitor. 

2.4 STARTING SYSTEM GENERATION 

Once the system generation disk is bootstrapped, the system gen- 
eration monitor runs. The user must perform the monitor dialogue and 
the login procedure; and initiate the batch command file. If magtape 
or DECtape distribution software is used, he must additionally trans- 
fer the batch command file from tape to the disk. 

2.4.1 Monitor Dialogue 

After the disk is bootstrapped, the system generation monitor 
prints its identification line followed by the first of several prompt- 
ing lines. Type the current date in response to DATE: and the current 
time of day in response to TIME: as shown below. Terminate each re- 
sponse with the RETURN key. 

DOS/BATCH V09-20 

DATE: 12-JUL-7 1 ) (Use dd-mmm-yy format.) 

TIME: 10:12 - " (Use hh:mm format.) 



DIALOGUE? 
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The user can omit the monitor dialogue if the line printer used 
for system generation is an LP11 with 80 columns and if the console 
fill count required is 0. 

To omit the dialogue, type the RETURN key in response to the 
DIALOGUE query. The monitor prints the $ character after which the 
user can continue at Section 2.4:2 to perform the login procedure. 

To include the dialogue type YES followed by the RETURN key in 
response to the DIALOGUE query and proceed as shown. 

D IALOGUE? YES 

DO YOU WANT TO SET CONSOLE FILL COUNT? YES 

FILL COUNT= 

Type the console fill count in response to the FILL COUNT= query 
according to the following values for the type of console terminal on 
the computer . 

Console Fill 

Values Console Terminal Types 

ASR-33 and ASR-3 5 Teletype; LA30S and LA30P 

DECwriter (110 and 150 baud) 

VT05 display (110, 150, and 300 baud) 

1 ASR-37 Teletype 

VT05B display at 600 baud 
4 LA30P DECwriter at 300 baud 

12 LA30S DECwriter at 300 baud 

For example, type 12 for an LA30S DECwriter at 300 baud. Type 
the RETURN key in response to the remaining questions as shown below 
unless the line printer is not an LP11 with 80 columns. 

FILL C0UNT= 12 

ARE ANY DEVICES DOWN? 

DO YOU WANT TO CHANGE LINE PRINTER? 

The question concerning the card reader appears only if the sys- 
tem has such a device. The monitor prints the $ character in response 
to which the user must perform the login procedure described in Sec- 
tion 2.4.2. 
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To change the line printer default, type YES in response to the 
line printer question and proceed as shown below. 

DO YOU WANT TO CHANGE LINE PRINTER? YES 

LS11? NO 

HOW MANY COLUMNS? 132 

LOW ER CASE? NO 

OVERPRINT? NO 

If unit is an LS11 dot-matrix line printer, type YES in response 
to the LSll query. Otherwise, type NO and the RETURN key to indicate 
an LPll line printer. Type the number of columns in response to the 
COLUMNS query. Type NO and the RETURN key in response to the LOWER 
CASE, OVERPRINT and remaining queries and proceed as described below 
when the $ character appears. 

2.4.2 Performing the Login Procedure 



com- 



To log into the system generation monitor, type the LO 1,1 
mand in response to the $ character as shown below. 

$L0 1,1 

DATE: 21-JUL-74 

TIME : 10:56 " 



If the login procedure is done properly, the monitor prints the 
current date and time followed by the $ character. Otherwise, the 
monitor prints an appropriate error message followed by the $ charac- 
ter. The user must try again. 

At this point, procedures differ slightly for tape and disk 
software. Continue with Section 2.4.3 if the software is on either 
magtape or DECtape. Proceed to Section 2.4.4 if the software is on 
disk cartridge. 

2.4.3 Transferring the Batch Command File from Tape 



:om- 



The user must execute the PIP program from tape and type a c< 
mand to transfer the batch command file to the system generation disk. 
Use the following format for the command to execute PIP. 

$RUN xx : PIP 
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where: 



xx is MT for either 7 -track or 9-track magtape or 
DT for DECtape. 

When PIP prints the identification line and the # character as 
follows: 



PIP V10-02 
# 



use the following format to transfer the file. 



#_ SY:<xx:SYSGEN 



where : 

xx is MT for either 7 -track or 9-track magtape or 
DT for DECtape. 

PIP signals completion by printing the # character again. Type 
the CTRL/C combination to terminate PIP and the KI command in response 
to the dot character printed by the monitor. For example, 

£+C 

.KI 

I 

When the monitor prints the $ character, proceed to Section 2.4.4 
to execute the batch command file. 

2.4.4 Initiating the Batch Command File 

To initiate execution of the first batch command file, type the 
following command in response to the $ character. 

$BATCH SYSGEN 
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The monitor executes the commands in the batch command file 
SYSGEN. When the following message and question is printed, SYSGEN. 
has entered the configuration dialogue. 

RSTS-11 V4B SYSTEM GENERATION 

DO YOU WANT QUESTIONS IN THE SHORT FORM(S) 
OR LONG (ANYTHING ELSE): 

Section 2.5 contains an explanation of the various forms of the 
questions. 

2.5 CONFIGURATION QUESTIONS 

After the user initiates the batch command file, the system 
generation program SYSGEN runs and enters a dialogue with the user. 
The dialogue is a series of approximately 45 hardware and software 
configuration questions. The questions come in both a long and a 
short form. 

Long form questions contain explanatory information and are 
useful to users who are unfamiliar with the system. For a sample 
printout of the long form questions, see Section 2.6.1. 

If the user is familiar with the dialogue questions, and wishes 
to save time, he can select the short form of the questions. A 
sample printout of the short form questions appears in Section 2.6.2. A 
tabulation of the short form questions and possible answers with 
comments is given in Appendix A. 

During the dialogue, SYSGEN checks the answers which the user 
gives. If an answer is incorrect, SYSGEN reprints the query or 
series of queries regarding that subject. Implications of the 
configuration questions are given in Section 2.7. 

After the user answers the configuration questions, the monitor 
begins executing the second batch command file. For information on 
this part of the procedure, consult Section 2.8. 
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2.6 SYSTEM GENERATION EXAMPLES 

This section contains two samples of system console terminal 
printout produced during the generation of RSTS • The right hand 
margin of each sample has references to other sections which contain 
relevant descriptions. The samples show the system generation to the 
point where the software automatically bootstraps the resultant RSTS 
system disk and loads the initialization code into memory for the 
first time. 

The first sample shows the output produced by using magtape soft- 
ware with an RK05 disk cartridge as the system generation disk and an 
RK05 disk cartridge as the resultant RSTS system disk. The sample 
shows all configuration questions in long form. 

The second sample shows a system generation using disk cartridge 
(DECpack) software. The system generation disk and the resultant 
RSTS system disk are RK05 disk cartridges. The sample shows short 
form configuration questions. 
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2.6.1 Magtape Distribution Software Using Long Form Questions 



RSTS-11 V4B SYSTEM GENERATION 

DO VOU WANT QUESTIONS IN THE SHORT FORM CS> (2.4.4) 

r < LONG (ANYTHING ELSE> : LONG 

VOU WILL BE ASKED A SERIES OF QUESTIONS (2.5) 

ABOUT VOUR PARTICULAR SVSTEM CONFIGURATION. 

EACH QUESTION WILL GIVE VOU THE PROPER 

RESPONSES. IF VOUR RESPONSE IS INVALID, THEN 

THE QUESTION WILL BE REPEATED AND VOU MAV TRV AGAIN 

FOR A VALID RESPONSE. VOU SHOULD CONTINUE TO USE 

THE LONG FORM OF THE QUESTIONS UNTIL VOU ARE 

VERV FAMILIAR WITH THE QUESTIONS AND 

THEIR ANSWERS. WHEN ALL QUESTIONS ARE DONE, 

THE CONFIGURATION FILE ' CF. MAC WILL BE WRITTEN OUT 

FOR USAGE IN ASSEMBLING THE RSTS FILES. 

A BATCH CONTROL FILE 'SVSGEN.BAT' WILL BE 
WRITTEN OUT THAT WILL COMPLETE THE GENERATION 
PROCEDURE. 

ENTER VOUR SVSTEM INSTALLATION NAME. IT 

MAV BE FROM 1 TO 14 CHARACTERS LONG. 

I WILL DRAW A LINE TO SHOW VOU HOW LONG A 14 

CHARACTER NAME WOULD BE: 

PLEASE ENTER NAME HERE: TEST 104 MT 

ENTER THE AC POWER FREQUENCY IN HERTZ. THE (2.7.1) 

ONLV RESPONSES ARE ' 60' AND "50'. 
ENTER VOUR FREQUENCY: 69 

IS VOUR CLOCK A KW11L (STANDARD LINE (2.7.2) 

FREQUENCY CLOCK;' OR fl KW11P < PROGRAMMABLE 
CLOCK). ANSWER ' L' FOR A KW11L OR 'P" FOR A 
KW11P. YOURS IS: L 

IF YOU WISH AUTOMATIC POWER FAIL RECOVERY, (2.7.3) 

THEN ANSWER THIS QUESTION WITH A "' V ; ELSE 
ANSWER WITH A ' N' . 
HOW ABOUT YOU: Y 

ENTER THE HIGHEST JOB NUMBER VOU WANT FOR VOUR (2.7.4) 

SVSTEM. IT MUST BE BETWEEN 1 AND 17. 
YOUR HIGHEST JOB NUMBER IS: 10 

ENTER NUMBER OF KL11 PLUS DL11A PLUS DL11B PLUS LC11 (2.7.5) 

TYPE INTERFACES ON THE SVSTEM. NOTE THAT THIS VALUE 
DOES NOT INCLUDE THE CONSOLE'S INTERFACE. THE VALUE, 
THEREFORE, HAS A RANGE OF & TO 16. 
YOU HAVE HOW MANY INTERFACES: 1 

ENTER NUMBER OF DC11 TYPE INTERFACES ON THE SVSTEM. 

THE VALUE IS BETWEEN B AND 16. 

VOU HAVE HOW MANY DC11 TYPE INTERFACES: 6 
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ENTER NUMBER OF DL11E TVPE INTERFACES ON THE SYSTEM. 

THE VALUE IS BETWEEN 8 AND 16. 

VOU HAVE HOW MANV DL11E TVPE INTERFACES: 1 

IF VOU DESIRE THE GENERALIZED TERMINAL FILL FEATURE (B.3) 

OF THE TERMINAL SERVICE, THEN ANSWER THIS QUESTION 
WITH -"V; ELSE ANSWER WITH ' N' FOR NO GENERALIZED 
FILL. VOU WANT: V 

IF VOU HAVE ANY SERIAL LA3@ TVPE TERMINALS, THEN 
ANSWER THIS QUESTION WITH ' V ; ELSE IF VOU DON'T 
HAVE ANV SERIAL LASS'S, THEN ANSWER WITH ' N" . 
ANV SERIAL LAM'S: V 

IF VOU HAVE UPPER/LOWER CASE TERMINALS, (B.2) 

VOU MAY WANT RSTS TO BE ABLE TO SELECT I VELV 

TRANSLATE LOWER CASE CHARACTERS TO UPPER 

CASE TO AVOID POSSIBLE PROBLEMS WITH STRING 

COMPARISONS. IF VOU WANT THIS FEATURE, ANSWER 

'V, ELSE ANSWER ' N'\ VOUR ANSWER: V 

SOME NEWER TERMINALS TREAT THE ASCII CHARACTERS" (B.l) 

175 & 176 AS REAL CHARACTERS, WHILE OLDER TERMINALS 

TREAT THESE AS ESCAPE CHARACTERS. VOUR RSTS SYSTEM 

CAN BE GENERATED TO SELECT I VELV DISABLE RECOGNITION 

OF THESE CHARACTERS AS ESCAPE. IF VOU WANT THIS 

FEATURE, ANSWER '" V , ELSE ANSWER ' N' . VOUR 

ANSWER IS: V 

ANSWER THIS QUESTION WITH ' V IF VOU HAVE REMOTE {B.4} 

TERMINALS SUCH AS AN ASR33 THAT HAVE THE LOCAL 
READER CONTROL FEATURE CALLED XONC +XOF F > . ANSWER 
WITH 'N' IF VOU DO NOT WANT THE XON FEATURE IN VOUR 
SVSTEM. VOU WANT: V 

IF VOU WANT THE TERMINALS THAT CALL IN TO VOUR (B.6) 

DRTASET TVPE INTERFACES TO GET AN AUTOMATIC ANSWER 
MESSAGE, THEN ANSWER THIS QUESTION WITH ' V'' .; ELSE 
ANSWER -N'" AND THEV WILL GET NO MESSAGE. 
DO VOU WANT MESSAGES: V 

IF VOU HAVE ANV SCOPE TVPE TERMINALS, THEN ANSWER 
QUESTION WITH '' V ; ELSE ANSWER ' N' AND VOU WILL NOT 
HAVE THE TERMINAL SERVICE SUPPORT FOR SCOPE TVPE 
TERMINALS. SCOPE SUPPORT: V 

THIS MULTIPLE CHOICE QUESTION IS ABOUT PARITY 

GENERATION FOR TERMINALS. VOUR ANSWER AFFECTS ALL (B.5) 

TERMINALS: 

'1-' NO PARITY GENERATION •:. 8 BITS SENDABLE> 

'•£"' EVEN PAR (TV GENERATED 

''j:'" ODD PARI TV GENERATED 

VOUR CHOICE: 1 

IF VOU DON'T HAVE THE RF11 256K FIXED HEAD DISK, (2.7.6) 

THEN ANSWER WITH A ' 6' . IF VOU DO HAVE THE RF11 DISK, 
ANSWER WITH THE NUMBER OF RS11 256K PLATTERS THAT ARE 
ON THE RF11 CONTROL (1 TO S>. 
VOUR ANSWER: 2 
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IF VOU HAVE THE RK11 CARTRIDGE DISK CONTROL ON 
VOUR SYSTEM, THEN ANSWER WITH THE NUMBER OF RKS3 
PLUS RK85 DRIVES THAT VOU HAVEC1 TO 8>. IF VOU DON' T 
HAVE THE RK11 ANSWER WITH A &. 
VOUR ANSWER IS: 2 

SINCE VOU HAVE BOTH AN RF11 AND AN (2.7.7) 

RK11 DISK, EITHER MflV BE USED AS THE 

RSTS-11 SVSTEM DISK. IF VOU ANSWER 

THIS QUESTION 'V, VOUR SVSTEM DISK 

WILL BE RK UNIT 8, AND THE RF DISK WILL 

BE USED ONLV FOR SWAPPING. IF VOU 

ANSWER 'N'\. THE RF11 WILL BE USED FOR 

BOTH SVSTEM AND SWAPPING. 

VOUR ANSWER: V 

IF VOU HAVE A HIGH SPEED PAPER TAPE READER, (2.7.8) 

THEN ANSWER 'V'i ELSE ANSWER ' N' . 
VOUR ANSWER IS: V 

IF VOU HAVE A HIGH SPEED PAPER TAPE PUNCH, 
THEN ANSWER ' V ; ELSE ANSWER ' N' . 
VOUR ANSWER IS: V 

ENTER NUMBER OF TU56 DUAL DECT APE DRIVES ON THE SVSTEM.. 

THIS WOULD BE H NUMBER FROM 1 TO 4 CORRESPONDING 

TO 2 TO 8 DECT APE DRIVES. IF VOU HAPPEN TO HAVE NO 

DECTAPE AT ALL THEN ANSWER S. 

VOUR NUMBER OF TU56 DUAL DRIVES IS: 1 

ENTER THE NUMBER OF BIG (256 WORD) BUFFERS (2.7.9) 

FOR VOUR SVSTEM. THE NUMBER IS FROM i TO THE 
NUMBER OF DECTAPE DRIVES 
NUMBER OF BIG BUFFERS: 1 

IF VOU HAVE A CARD READER (BE IT THE CR11 (2.7.10) 

PUNCHED CARD READER OR THE CM11 MARK SENSE CARD 
READER) THEN ANSWER 'V'i ANSWER ' N' FOR NO CARD 
READER. VOUR ANSWER: N 

IF VOU HAVE THE LP11 LINE PRINTER, THEN ANSWER 
WITH A 'V; ELSE ANSWER ' N' FOR NO LINE PRINTER. 
VOUR ANSWER: V 

IS VOUR LINE-PRINTER A CENTRONICS 
,<LS11) LINE PRINTER: V 

IF VOU HAVE THE TM11 MAGTAPE CONTROL, THEN ANSWER 

WITH THE NUMBER OF TU1S DRIVES (.7 TRACK PLUS 

3 TRACK). IF VOU HAVE NO MAGTAPE, THEN ANSWER WITH 

fl @. THE RANGE OF NUMBER OF DRIVES 

IS FROM 1 TO 8. NUMBER OF TUIO DRIVES: 2 

ENTER THE NUMBER OF SMALL CIS WORD) BUFFERS VOU WISH (2.7.11) 

TO HAVE FOR VOUR SVSTEM. 64 SMALL BUFFERS 

SEEMS TO BE A GOODLV NUMBER. THE RANGE IS FROM 

18 TO 999 SMALL BUFFERS. THE NUMBER OF SMALL BUFFERS 

FOR OPTIMUM SVSTEM OPERATION IS A FUNCTION OF THE 

NUMBER OF JOBS POSSIBLE AND HOW MANV FILES THOSE JOBS 

WILL HAVE OPEN AT ONCE. NUMBER OF SMALL BUFFERS: 75 
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SELECT VOUR MATH PACKAGE FROM THE LIST. 

2 STANDARD 2-WORD MATH 

2E 2-WORD EAE MA t H 

2X STANDARD 2- WORD WITH NO FUNCTIONS 

2EX 2-WORD EAE WITH NO FUNCTIONS 

4 STANDARD 4-WORD MATH 

4E 4-WORD EAE MATH 

4X STANDARD 4- WORD WITH NO FUNCTIONS 

4 EX 4- WORD EAE WITH NO FUNCTIONS 

ENTER MATH PACKAGE DESIRED: 4 

VOUR RSTS-11 SVSTEM CAN PRINT THE TIME 
OF DAV IN 24-HOUR MILITARV FORMAT OR 
IN STANDARD RM/PM FORMAT. IF VOU 
ANSWER 'V, 24-HOUR TIME WILL BE 
U S E D . IF V U A N S W E R '' N '' , A M ,-' P M WILL 
BE USED. THE DEFAUL'' IS RM/PM DO VOU 
WANT 24-HOUR TIME: N 

THE FOLLOWING QUESTIONS ARE ABOUT OPTIONAL SPECIAL 
FEATURES. IF VOU WANT THE FEATURE DESCRIBED.. THEN 
ANSWER WITH A ■' V ; ELSE ANSWER WITH ' N' TO OMIT 
THE FEATURE. 

ALL RSTS V4B SVSTEMS GET THE AUTOMATIC SVSTEM RELOAD 
AND RE-START FOLLOWING A SVSTEM ERROR, BUT THERE ARE 
SPECIAL ROUTINES THAT ATTEMPT TO RECOVER FROM MOST OF 
THESE ERRORS WITHOUT AFFECTING MORE THAN THE USER THAT- 
CAUSED THE ERROR. DO VOU WANT THESE ROUTINES: V 

THE RECORD I/O FEATURE ENABLES THE VERBS: 

LSET, RSET, FIELD, GET, PUT, CVT, XLATE. 
DO VOU WANT THE RECORD I/O FEATURE: V 

DO VOU WANT THE FILE 'UPDATE-' MODE FEATURE' V 

DO VOU WANT 'PRINT-USING'' INCLUDED: V 

DO VOU WANT THE 'MAT' COMMANDS: V 

IF VOU WISH LINE PRINTER LISTINGS OF THE RSTS 
ASSEMBLIES THAT ARE TO FOLLOW, THEN ANSWER WITH 
A "V; ELSE ANSWER WITH ' N' FOR NO LISTINGS. 
VOUR ANSWER: N 

PLEASE INDICATE VOUR RSTS-11 
DISTRIBUTION MEDIA FROM THE LIST 
BELOW. 

DT DEC-TAPE 

NT MAG-TAPE 

DK DEC-PACK 
VOUR MEDIA IS: MT 

THERE ARE TWO OPTIONAL MODULES THAT VOU CRN INCLUDE 
AND SAVE ON VOUR RSTS SVSTEM DISK FOP LATER CALLING. 
THEV ARE: 
DSKINT RSTS V4B DISK INITIALIZATION PROGRAM 

I NIT IS USED TO CREATE RSTS V4B NON-SVSTEM 

DISKS. 
ROLLIN ROLLIN-ROLLOUT D I SK+DECTAPE+NRGTRPE COPV 

ROLL IN IS USED TO DUMP OR LOAD DISKS TO OR 

FROM EITHER DECTRPE OP MAGTAPE. 



(2.7.12) 



(2.7.13) 

(2.7.14) 
(2.7.15) 
(2.7.16) 
(2.7.17) 



Februarv 1 91 R 



2-22 



ANSWER THE QUESTION ABOUT THE MODULE'' S NAME WITH 
EITHER 'V TO INCLUDE THE MODULE OR 'N' TO OMIT 
THE MODULE. 

I N C L U D E M D U L E ' D SKIN T ' : V 

INCLUDE MODULE 'ROLLIN': V 

2.6.2 Disk Cartridge Distribution Software Using Short Form Questions 



RSTS-11 V4B SV5TEM GENERATION 

DO VOU WANT QUESTIONS IN THE SHORT FORM <S> (2.4.4} 

OR LONG CftNVTHING ELSE> : S (2.5) 

NAME OF' INSTALLATION: TEST 104 RK 

AC FREQUENCV: 66 (2.7.1) 

CLOCK: L (2.7.2) 

POWER FAIL: V (2.7.3) 

MAX JOB NUMBER: 10 (2.7.4) 

KLll+DLllA+DLllB+LCll'S: 2 (2.7.5) 

DC11'' S : 1 

DLllE'S: 1 

FILL: V (B.3) 

SERIAL LASS'S: V 

LOWER CASE: V ( B - 2 ) 

ESCAPE: V (B- 1 ) 

XQN: V (B.4) 

AUTO ANSWER: V (B.6) 

SCOPES : V 

PARITV: 1 (B-5) 

RF11 : 2 

RK11: 2 (2.7.6) 

SWAP ONLV RF: V (2.7.7) 

PT READER: V (2.7.8) 

PT PUNCH: V 



TC11: 1 
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BIG BUFFERS: 1 (2.7.9) 

CR11: N 

LF'll: V 

LS11 TVPE: N 

LP COLUMNS: 132 

LP LC: N 

LP FORMAT: V 

TM11: 2 

SMALL BUFFERS: 75 (2.7.11) 

MfiTH PACKAGE: 2 (2.7.12) 

24-HOUR TIME: N 

NO FAIL: V 

RECORD I/O; V (2.7.13) 

UPDATE: V (2.7.14) 

PRINT-USING: V (2.7.15) 

MATRIX: V (2.7.16) 

LP LISTINGS: N (2.7.17) 

MEDIA: DK 

DSKINT: V 

ROLLIN: V (2.7.18) 
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2.7 CONFIGURATION QUESTION CONSIDERATIONS 

The questions printed by the SYSGEN system generation program 
and shown in Section 2.6 concern the hardware configuration param- 
eters and software options. Those parameters and options requiring 
more explanation than available in the long form of the question are 
explained in this section. The explanations appear in the order in 
which the program prints the related questions . 

2.7.1 AC Power Frequency 

The PDP-11 computer requires alternating current power input and 
is able to run on either a 60 Hertz (Hz) line, as is standard in the 
U.S. A., 'or a 50 Hertz (Hz) line which is standard in most European 
and Asian countries. (Hertz is the international standard of measure- 
ment for cycles per second.) The user must specify what the line fre- 
quency of his power source is. 

2.7.2 Clocks 

The RSTS system can operate with two types of system clocks. 
The KW11-L Line Time Clock divides time into intervals determined by 
the line frequency of the power source, either 50 Hz or 60 Hz. In 
areas where the line frequency of the power source is not dependable, 
the KW11-P Programmable Real Time Clock is recommended since its time 
base is derived from a crystal oscillator. 

2.7.3 Power Fail Recovery Code 

RSTS systems can attempt to recover from a momentary power fail- 
ure by performing an automatic restart procedure. A momentary power 
failure is defined in Section 2.7.1 of both the PDP-11/411 Processor 
Handbook and PDP-11/45 Processor Handbook and in Section 2.2.4 of the 
PDP-11/20 Processor Handbook . 

2.7.4 Maximum Number of Jobs 

With sufficient hardware, RSTS can handle up to 16 simultaneous 
jobs. The user must specify the maximum number of jobs at system 
generation time since this parameter determines the size of several 

monitor tables. 
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The maximum number uf jubs the User may CuiifiyUXe prOpex ly and 
utilize efficiently depends on the memory space available and the 
number and type of swapping disks on the system. Memory space require- 
ments are discussed in Chapter 1. 

Jobs on the system are numbered sequentially from one to the 
maximum number the system can handle. Jobs include both those attached 
and detached. 

2.7.5 Terminals 

The RSTS system is designed to handle a maximum of 16 terminals. 
Each terminal is assigned a keyboard number ranging from to 15. The 
console terminal is given the keyboard number on all RSTS systems 
and is referenced by the device designator KBjZf : . (Refer to Section 9.1 
of the BASIC-PLUS Language Manual for the definition of device desig- 
nators. ) 

The assignment of a keyboard number, other than that of the con- 
sole terminal, is determined by the type of line interface to which 
the terminal is attached. The local installation can have any com- 
bination of local and remote line interfaces as long as the total 
number of terminal lines does not exceed 15, not including the console 
terminal. 

The order in which SYSGEN assigns keyboard numbers is as follows: 
the system console terminal; all KL11 , LC11, DL11A, and DL11B lines; 
DCll (remote dial) ; and DLllE (remote dial) . The answers to the con- 
figuration questions concerning the number of each type of terminal 
interface must accurately reflect the hardware configuration. 

2.7.6 Disk Devices 

Disks in the RSTS system operate in either the public or private 
structure. The disk which contains the system accounts and executable 
code of RSTS is called the system disk and is the first of the public 
structure. All other disks in the system are referred to collectively 
as non-system disks. 

The most practical use of the system disk on the RSTS system is 

as a removable disk as opposed to a fixed head disk. If the system 
disk is fiither an RK.05 or RKPH riiak oarrridgfi, it can be removed from 
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the computer area when the system is not operating and kept in a safe 
place, thereby reducing the chances of inadvertent or malicious de- 
struction. To preserve the contents of an RFll fixed head disk, a 
copy must be transferred to a back up medium each time the system is 
shut down. 

Optimum performance is obtained if the system is configured with 
a moving head disk (removable) and an auxiliary swapping disk (fixed 
head) . With such a configuration, the swapping of user jobs into and 
out of memory is faster and more efficient. Disk accessing operations 
on the moving head system device can then be confined to manipulating 
user files and directories while the faster fixed head device takes 
on the burden of moving user jobs into and out of memory. In such a 
case, the auxiliary swapping disk acts as a logical extension of the 
system disk while the system is operating but contains no valuable 
system data when the system is not operating. At the start of time 
sharing operations, the initialization code creates the necessary 
files on the auxiliary swapping device. 

2.7.7 The RFll Disk as a Swap Only Disk 

If the user indicates that both RFll and RK11 disks are on the 
RSTS system, SYSGEN prints the question SWAP ONLY RF . The response 
to this question determines whether the user wishes to employ the 
fixed head disk (RFll) for swapping only and not for system use or 
wishes the RFll to be used as the system disk (for swapping and sys- 
tem use) . 

Designating the RFll disk for swapping only means that the 
RK11 disk is the system disk. Therefore, the RSTS Core Image Library 
resides on the RK03 or RK05 unit 0. The maximum amount of space on 
the RFll disk will be available for swapping only. Ail RFll platters 
are considered a logical extension of the system disk unit DK0: but 
the RFll disk space cannot be referenced explicitly by users. To 
preserve user and system files, the disk cartridge can be removed 
from the machine when RSTS is not running. 

By rejecting the RFll for swap only operation, the user chooses 
the RFll as the system disk. The Core Image Library and the swapping 
file (SWAP. SYS [0 , 1] ) both reside on the RFll. Additionally, user 
files to which rapid access is necessary can be located on the RFll. 
All platters on the RFll are a single logical device under RSTS 
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(accessed by the designation DF : or DF0:). With this configuration, 
less space exists for swapping. To preserve system and user files, 
the contents of the RFll must be copied to a back up medium and 
stored in a safe place when RSTS is not running. 

To select the RK11 as the system disk, type YES in response 
to the SWAP ONLY RF question. To select the RFll as the system 
disk, type NO in response to the SWAP ONLY RF question. 

2.7.8 Peripheral Devices 

The use of peripheral devices in the RSTS system reduces the 
burden of storage requirements on the disk devices and provides a 
convenient means of file back-up. Program and data files that are 
not frequently used can be stored on magnetic tape (DECtape or mag- 
tape) , paper tape (high speed, fan-folded or Teletype) , an^ car^s 
(marked or punched) and accessed readily when required. Media such 
as DECtape and magtape provide a large capacity storage back-up for 
critical file information. 

2.7.9 Big Buffers 

Big buffers are 256-word blocks of monitor memory used for DEC- 
tape operations. SYSGEN prints the BIG BUFFER question only if DEC- 
tape is on the system. On systems with DECtape devices, provide one 
big buffer for each DECtape drive. However, one big buffer per drive 
is not a definite requirement since one big buffer can accommodate 
any number of DECtape drives for non-simultaneous operations. Experi- 
ence indicates that, unless DECtape usage is heavy, two big buffers 
are sufficient even for four drives <. Three big buffers are recom- 
mended for six drives and four big buffers are recommended for eight 
DECtape drives. 

2.7.10 Card Codes 

If the RSTS system has a CRll card reader, the user must con- 
figure one of three card codes. These card codes are presented for 
reference in Appendix D.3 of the BASIC-PLUS Language Manual . The 
default card code is DEC029 code. 

February 1975 

2-28 



2.7.11 Small Buffers 

The RSTS system handles transfer requests and file processing 
requests by means of intermediate memory storage, called small buf- 
fers. These buffers are considered a system resource, and the user 
must assign a sufficient number of each type at system generation time. 
If an insufficient number of either type is assigned, jobs running on 
the system can become stalled waiting until enough buffers are freed 
by jobs currently claiming their use. 

Small buffers are 16-word blocks residing in the Monitor part 
of memory. The number needed by a system at any one time depends 
upon the dynamic requirements of the jobs on the system. The user 
must approximate the number of small buffers that his system can 
reasonably be expected to use at any one time and assign that number 
at system generation time. 

For efficient system operation, it is recommended that at least 
8 small buffers be allocated for each possible job. Thus, on a 16- 
user system, 128 small buffers should be available. (An indicator 
of good system performance is that the number of free small buffers, 
as reported by the SYSTAT system program, never drops below ten. 
Refer to the description of SYSTAT in Section 5.6 of this guide.) 

On systems configured for fewer than 16 jobs, it is necessary 
to include more than 8 small buffers per job. For example, each 
active terminal requires 4 or 5 small buffers for performing input 
and output operations. A system having 8 terminals therefore needs 
between 32 and 40 small buffers if all terminals are to be simultane- 
ously active. Each active job requires 2 small buffers. Thus, if 
the same system required that ten jobs be able to run simultaneously, 
20 more small buffers would be needed. For each job that will run 
detached from all terminals, subtract the four small buffers required 
for terminal I/O. A running total on the 8 -terminal, 10- job system 
is 52 small buffers for these two simple processing requirements. 

Next, in the sample system, consider what kind of processing is 
necessary. One small buffer must be added for each open file on the 
system. If each program running on the system opens two disk files, 
20 more small buffers must be added. If all the active programs open 

the maximum number of files simultaneously, 120 small buffers must be 
available. (BASIC-PLUS allows 12 open channels per user program.) 
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In an average system, the two file situation is much more likely, so 
the sample system requires 20 more small buffers for a total of 72. 

The system requires small buffers for certain transient opera- 
tions. One small buffer is used for each disk transfer queued by the 
monitor. On the 10 job, S termi.na.i_ system,- a reasonauxe number is 
approximately 20 more small buffers. 

A line printer on the system exhausts as many as 19 available 
small buffers. A lower number of available small buffers places a 
larger burden on the system. For example, if 19 small buffers are 
available for use by the printer driver, the system can have 570 
characters buffered for output to the line printer. Assume that a 
line printer is running at 300 lines per minute (5 lines per second) 
and that an average line is 90 characters. Such a line printer 
empties the buffers in 1.2 seconds. A spooling program for that line 
printer would have to be swapped into memory every 1.2 seconds to 
keep the line printer running at full speed.. (For a line printer 
running at 120J0 lines per minute, a swap operation would be necessary 
every 0.3 seconds.) 

The total requirement on the 10 job, 8 terminal system is 111 
small buffers for an average system load if the transient requirement 
for 10 is added and 19 buffers are added to handle the line printer 
running full speed (300 lines per minute) . Thus, the guideline 
of 8 small buffers per job is too low on such a small system. 
Moreover, if small buffers were subtracted from 111 to account for 
idle terminals and detached jobs and to allow for some slow down in 
line printer operations, the guideline is still inadequate. On such 
a system, between 12 and 14 small buffers per job is a better approxi- 
mation. For larger systems having 10 or more jobs, eight small buf- 
fers per job is usually a good approximation. Except for occasions 
of heavy keyboard and line printer activity, enough free small buffers 
can be available to maintain good system throughput. 

2.7.12 Floating Point Precision and Math Package Selection 

The user can select either single precision (2-word) or double 
precision (4-word) floating point format for the type of numeric for- 
mat to be used on his system. These floating point formats are 
described in Appendix F.l of the BASIC-PLUS Language Manual . 
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The user can conserve memory space by omitting certain mathematical 
functions including SIN, COS, TAN, ATN, SQR, EXP, LOG, and LOG10. These 
functions are described in Section 3.7 of the BASIC -PLUS Language 
Manual and summarized in Table 3-1 of that section. 

The following list summarizes the math packages available. 1 

MA2 2-word, non-EAE, with functions 

MA2E 2-word, with EAE, with functions 

MA2X 2-word, non-EAE, without functions 

MA2EX 2 -word, with EAE, without functions 

MA4 4-word, non-EAE, with functions 

MA4E 4-word, with EAE, with functions 

MA4X 4-word, non-EAE, without functions 

MA4EX 4-word, with EAE, without functions 

2.7.13 Record I/O Software 

Record I/O software in a RSTS system allows a user program to 
perform input and output of fixed length records and enables a user 
to include update and PRINT USING software on the system. Record I/O 
is explained in Chapter 11 of the BASIC-PLUS Language Manual . 

2.7.14 Update Software 

If Record I/O software is configured on the system, SYSGEN asks 
whether the update software is to be included in the system. This 
software enables multiple user programs to open a file and, at the 
same time, update its contents provided the same physical block is 
not affected. Section 12.2 of the BASIC-PLUS Language Manual de- 
scribes the update feature. 

2.7.15 PRINT USING Option 

If the user configures Record I/O software, he can include the 
PRINT USING optional feature in his software configuration. With 
PRINT USING software, BASIC-PLUS programs can perform special format- 
ting of output as described in Section 10.4.1 of the BASIC-PLUS Lan - 
guage Manual. 



The packages with EAE require the KE11-A Extended Arithmetic Element 
which is used in place of slower non-EAE software routines. The EAE 

unit is not the same as the KE11-E EIS option on the PDP-11/40 com- 
puter. 
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2.7.16 Matrix Manipulation 

BASIC-PLUS can operate on an entire matrix using single statements 
called MAT statements as described in Chapter 7 of the BASIC-PLUS Lan - 
guage Manual . The user must configure this optional feature if he 
wants to include the matrix manipulation capability. 

2.7.17 Listings 

During the system generation process, the system tables, disk 
service and terminal service modules are assembled. Since each of 
the assemblies is unique to an installation, the related listings 
provide information valuable for documentation and maintenance pur- 
poses. If the user answers the LP11 question with YES, SYSGEN prints 
the LISTINGS question to allow him to have the listings printed dur- 
ing the system generation process. If the answer to the LPll question 
is NO, SYSGEN does not print the LISTINGS query. 

To print the listings at system generation time, simply type 
YES in response to the LISTINGS question. As a result, the listings 
are automatically printed later in the system generation process. 
The listings are quite lengthy and take approximately 30 minutes to 
print on a 300 line per minute printer. To omit printing the list- 
ings, type NO to the related question. 

2.7.18 Stand Alone Programs 

The user can include stand alone programs in the RSTS Core Image 
Library (CIL) . Any program included in the CIL can be bootstrapped 
into memory using the LOAD option at initialization time as described 
in Chapter 3. The DEC-supplied programs that can be included in the 
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ment entitled PDP-11 ROLLIN Utility Program , order number DEC-11- 
OROAA-B-D. The document is included in the RSTS software package. 
DSKINT formats and initializes disks for use under RSTS and is 
described in Section 6.2 of this manual. 

2.8 LOADING THE CIL ONTO THE RSTS SYSTEM DISK 

After the user answers the configuration question concerning 

ROLLIN, the SYSGEN program completes building the configuration file 
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monitor executes commands in the second batch command file and gen- 
erates the RSTS linked core image library (LICIL) and any listings 
necessary. 

During the generation, messages are printed telling the user 
which devices to mount and how to proceed. The entire process takes 
between one and 3 hours depending upon the devices used and the 
types of listings requested. If either magtape or DECtape software 
is employed, the user must mount a new, formatted tape to which the 
RSTS LICIL is written. Instructions are printed telling the user to 
mount his RSTS system disk on unit and showing the exact command 
to transfer the LICIL to the disk. If disk cartridge software is 
used, instructions are printed telling the user to mount a new car- 
tridge or pack to be used as the RSTS system disk. 

After the CIL is written on the RSTS system disk and the RSTS 
code is loaded into memory for the first time, the user must run the 
PATCH option described in Section 3.3.5, run the REFRESH and START 
options described in Section 2.10, and build the system library as 
described in Sections 2.11 and 2.12. 

2.9 SYSLOD AND CILUS COMMAND STRINGS 

This section describes the procedures and command strings em- 
ployed in loading the RSTS Linked Core Image Library (LICIL) onto 
the RSTS system disk. All necessary instructions to perform the load 
operation are printed during the system generation procedure. If the 
user follows the standard procedure, he need not refer to the contents 
of this section. However, the command strings documented here are 
useful if the load operation is not performed as part of the system 
generation procedure or if the newly created LICIL must replace an 
old RSTS Core Image Library (CIL) on an existing system disk. 

The load operation occurs as part of the final step of the sys- 
tem generation process. During the final step, either the user per- 
forms the load operation by executing a SYSLOD command string (mag- 
tape and DECtape distribution software) or the batch stream executes 
a CILUS command string (disk cartridge distribution) . In both cases, 
the user can interrupt the process and perform the loading operation 
in other than the standard manner. 
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The final step of the system generation process for magtape and 
DECtape distribution software includes writing the newly created 
Linked Core Image Library to tape along with a copy of the SYSLOD 
program, the batch and configuration files, and system load maps. 
The SYSGEN program prints the SYSLOD command string that the user 
must type to load the RSTS LICIL from tape to the RSTS system disk. 
SYSGEN terminates by bootstrapping SYSLOD into memory. If the user 
preserves the tape, he can later bootstrap it to load SYSLOD and can 
execute the appropriate SYSLOD dialogue and command string to perform 
the load operation. 

For disk cartridge distribution, the final step of the system 
generation includes loading the RSTS Core Image Library onto the 
RSTS system disk. The newly created Linked Core Image Library re- 
sides on the system generation disk cartridge along with the batch 
and configuration files, system load maps, and the CILUS program. 
Because the batch stream performs the loading operation, the actual 
command string is never printed. However, the user can terminate 
the batch stream when SYSGEN waits for the RSTS system disk to be 
mounted before the load operation begins. By preserving the system 
generation disk and following the procedures described in this sec- 
tion, the user can run CILUS to perform the load operation. 

Because the user can perform the load operation using either a 
blank or an existing system disk, two general operations are de- 
scribed. Section 2.9.1 presents the procedures to load a new RSTS 
system onto a disk which contains no user files to be preserved. 
Section 2.9.2 describes guidelines for replacing an existing RSTS 
system on a system disk containing system and user files which must 
be preserved. 
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The procedure and command strings detailed in this section apply 
only to loading a CIL onto a blank system disk. It is possible to 
overwrite an existing CIL on a system disk which contains system and 
user files without destroying the file structure. This latter proce- 
dure is described in Section 2.9.2. The procedures below destroy 
any existing file structure on the disk being initialized as the 
RSTS system disk. 
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2.9.1.1 DECtape and Magtape Procedures Using SYSLOD - The tape cre- 
ated during system generation contains a copy of the stand-alone pro- 
gram SYSLOD. SYSLOD is loaded from DECtape using either the BM7 92-YB 
hardware bootstrap loader or the MRll-DB Bulk Storage Loader. Refer 
to Section 2.2.2 for standard DECtape bootstrap procedures. SYSLOD 
can be bootstrapped from magtape using the MRll-DB Bulk Storage Loader. 
A small magtape bootstrap must be manually loaded into memory using 
the console switches if the configuration does not include the MRll-DB. 
Section 2.2.1 contains magtape bootstrap procedures. When SYSLOD is 
bootstrapped into memory, it identifies itself by printing the follow- 
ing lines. 



SYSLOD V07-02A 

CONSOLE FILL COUNT= Type the RETURN key 

DATE : DD-MMM-YY '" Type the date in format shown 

DIALOGUE? 

I 

Before answering the DIALOGUE query, mount and write enable the 
disk to be used as the RSTS system disk. In the case of an RK system 
disk, an RK cartridge must be mounted on RK unit 0. No special action 
is required for an RF system disk. SYSLOD will not recognize any 
device which is not mounted and ready when the DIALOGUE query is 
answered. The RETURN key is sufficient response to the DIALOGUE query. 
SYSLOD responds by printing the pound sign (#) when it is ready to ac- 
cept a command. A single command string is sufficient to create and 
load the CIL onto the system disk and bootstrap the RSTS Initializa- 
tion code into memory. The exact command which must be entered de- 
pends on the type of system disk. If any error messages are printed 
while or after the command string is entered, consult Appendix C for 
the proper procedure to follow. The following command strings are 
used for the several types of system disks. 

DF:/NS: 256 :17/HO/BO<DT0: RSTS. LCL (To RF System Disk from DECtape) 
DF:/NS: 256: 17/HO/BO<MT0: RSTS. LCL (To RF System Disk from Magtape) 

DK:/NS:256:17/FO/HO/BO<DT0:RSTS.LCL (To RK System Disk from DECtape) 
DK:/NS: 256 :17/FO/HO/BO<MT0: RSTS. LCL (To RK System Disk from Magtape) 

Upon completion of the load operation, the RSTS Initialization 
code is bootstrapped into memory signalled by the printing of the 
OPTION query. The system manager should proceed to execute the 
REFRESH option according to the procedures described in Section 2.10. 
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2.9.1.2 Disk Cartridge Procedures Using CILUS 

When disk cartridge distribution software is used, the DOS pro- 
gram CILUS is used to load the RSTS CIL onto the system disk. CILUS 
will not format an RK cartridge. An RK disk should be formatted 
using ROLLIN prior to loading the CIL. Refer to Section 2.3.2 for 
procedures to load ROLLIN and format disks. 

Mount the copy of the System Generation disk cartridge used for 
the system generation on RK unit 0. Write-enable the drive and boot- 
strap the cartridge to load the DOS/BATCH monitor. Refer to Sec- 
tion 2.3.1 for bootstrap procedures. When the DOS monitor identifies 
itself, proceed as shown below to run CILUS. 

DOS/BATCH V09-20 

DATE: DD-MMM-YY Type the date in format shown 

TIME: HH:MM Type the time in format shown 

DIALOGUE? <CR> <CR> denotes typing the RETURN key 

$L0 1,1 

DATE: 22-JUL-7^ 
TIME: 12:30 

$RUN CILUS 

CILUS V06-07 
£ 

CILUS prints the pound sign (#) when it is ready to accept a 
command. The CILUS command string used to create and load the RSTS 
CIL depends on the type of system disk. If the system is configured 
for an RK system disk, mount a newly formatted RK cartridge on RK 
unit 1. No special action is required for an RF system disk. One 
of the CILUS commands shown below is then used to load the CIL. 

DF:/NS: 256 :17/HO/BO<DK0: RSTS. LCL/LO (To RF System Disk from RK cartridge) 
DK1:/NS: 256 :17/HO<DK0: RSTS. LCL/LO (To RK System Disk from RK cartridge) 

If the system disk is an RF11, the CILUS command loads the CIL 
and then bootstraps the RSTS initialization code into memory. The 
INIT code prints the system name followed by the OPTION query. The 
system manager should proceed to execute the REFRESH as described in 
Section 2.10. 

The command to load the CIL onto the RK cartridge mounted on 
unit 1 does not Dootstrap the RSTb initialization code. vJiien the 
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load operation is complete, CILUS reprints the pound sign (#) and 
waits for another command. The system manager should exit from 
CILUS and terminate the DOS monitor as shown below. 

#"C CONTROL/C exit from CILUS 

JCi "KILL" required by DOS 

$FI Finish for an orderly exit 

TIME: HH:MM:SS 
DOS/BATCH V09-20 

$ 

The processor should be halted by moving the HALT/ENABLE switch 
to the HALT position. Dismount both cartridges and move the RSTS 
system disk to RK unit 0. When the disk is ready, write-enable the 
drive and bootstrap the disk cartridge (see Section 2.3.1) to load 
the RSTS initialization code into memory. Proceed to Section 2.10 
to refresh the new system disk. 

2.9.2 Replacing the RSTS System Code 

It is possible to replace the RSTS CIL on the system disk with- 
out destroying the file structure. This could be done when a new 
system is generated to add or change hardware support or software 
features. The SYSLOD or CILUS command strings used for this purpose 
are similar to those in the previous sections but several precautions 
should be taken to ensure a successful replacement. Careful adherence 
to these procedures is critical to avoid destroying the existing file 
structures (system and user files) on the system disk. 

It is impossible to determine the exact size of the new CIL until 
it is loaded onto a disk. The first step, therefore, is to load the 
new monitor onto a scratch disk using the standard system generation 
procedures or the SYSLOD or CILUS commands described in Sections 
2.9.1.1 and 2.9.1.2. The user must create the required system files 
on the scratch disk by using the REFRESH option described in Sec- 
tion 2.10.1. To determine the required size of the new Core Image 
Library, the user must start time sharing (START option in Section 
2.10.2) and execute the CATALOG [0,1] command which prints the length 
of the new CIL file CORE. SYS [0,1] . 

The next step is to determine the size of the old CIL which will 

be replaced. Simply obtain a directory of the system files account 

[0,1] under time sharing by using the CATALOG [0,1] command. The 
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important thing to look for is the current size of the CORE. SYS file 
on the system disk. The REFRESH procedures of Section 2.10.1 recom- 
mend that this file be made larger than the required size when the 
system disk is initially built. If the system manager planned for a 
future replacement of the system code, the current size of the old 
CORE. SYS file is probably larger than the required size of the new 
CORE. SYS file and the replacement can proceed as described in sub- 
sequent paragraphs. Otherwise, the replacement cannot be performed. 
All library and user files must be transferred to another disk or 
external medium and the system disk must be initialized (destroying 
the existing file structure) . 

Assuming the CORE. SYS [0,1] file on the system disk is large 
enough to accommodate the new CIL, the next step is to create backup 
copies of all library and user files on the system disk. This is a 
time consuming but important precaution since a typographical error 
or a hardware malfunction while replacing the old CIL could be dis- 
astrous. The user must perform the backup operation under time 
sharing using the old system. The next two sections present the 
SYSLOD and CILUS command strings used to replace the old CIL. 

2.9.2.1 DECtape and Magtape Procedures Using SYSLOD 

The tape created during system generation contains a copy of the 
stand-alone program SYSLOD. SYSLOD is loaded from DECtape using 
either the BM792-YB hardware bootstrap loader or the MR11-DB bulk 
storage loader. Refer to Section 2.2.2 for standard DECtape bootstrap 
procedures. SYSLOD can be bootstrapped from magtape using the MRll-DB 
bulk storage loader. A small magtape bootstrap must be manually 
loaded into memory using the console switches if the configuration 
does not include the MRll-DB. Section 2.2.1 contains magtape boot- 
strap procedures. When SYSLOD is bootstrapped into memory, it will 
identify itself by printing the following lines. 

SYSLOD V07-02A 

CONSOLE FILL COUNT= Type the RETURN key 

DATE : DD-MMM-YY " Type the date in format shown 

DIALOGUE? 

t 

Before the DIALOGUE query is answered, the old RSTS system disk 
should be mounted and write enabled. In the case of an RK system 
disk, the cartridge must be mounted on RK unit J3 . SYSLOD will not 






2-38 



recognize any device which is not mounted and ready when the DIALOGUE 
query is answered. The RETURN key is sufficient response to the DIA- 
LOGUE query. SYSLOD responds by printing the pound sign (#) when it 
is ready to accept a command. The following SYSLOD commands are used 
to replace an old CIL on the various types of system disks. 

DF:/NS:256:17/HO/BO/BL:nnn<DT0:RSTS.LCL (To RF System Disk from DEC- 

tape) 

DP:/NS:256:17/KO/BO/BL:nnn<MT0:RSTS.LCL (To RF System Disk from Mag- 
tape) 

DK:/NS:256:17/HO/BO/BL:nnn<DT0:RSTS.LCL (To RK System Disk from DEC- 

tape) 

DK:/NS: 256 :17/HO/BO/BL:nnn<MT0: RSTS. LCL (To RK System Disk from Mag- 
tape) 

NOTE 

In place of nnn in the /BL:nnn switch, 

the user must type the size of the old 

RSTS CIL. The switch prevents SYSLOD 

from loading the new CIL if it is larger 
than the old CIL. 

The only differences between these SYSLOD commands for replacing 
a CIL and those used for a blank system disk are the absence of the 
format switch (/FO) for RK system disks and the addition of the /BL:nnn 
switch. 

Upon completion of the load operation, the RSTS Initialization 
code is bootstrapped into memory signalled by the printing of the 
OPTION query. The system manager must reinstall all published patches 
using the PATCH option (see Section 3.3.5) before time sharing opera- 
tions can resume with the new system. The REFRESH initialization op- 
tion is not used in this case since initializing a disk destroys any 
existing file structures. 

2.9.2.2 DECpack Procedures Using CILUS 

When disk cartridge software is used, the DOS program CILUS is 
used to load the new CIL onto the old system disk. Since CILUS does 
not format an RK cartridge, the CILUS commands are nearly the same as 
for loading a CIL onto a blank system disk. The CILUS procedures are 
repeated below for continuity. 

Mount the copy of the System Generation disk cartridge used for 
the system generation on RK unit 0. Write-enable the drive and boot- 
February 197 5 
2-39 



strap the cartridge to load the DOS/BATCH Monitor. Refer to Sec- 
tion 2.2.2 for disk cartridge bootstrap procedures. When the DOS 
Monitor identifies itself, proceed as shown below to run CILUS. 

DOS/BATCH V09-20 

DATE : DD-MMM-YY Type the date in format shown 

TIME : HH:MM Type the time in format shown 

DIALOGUE? <CR> <CR> denotes typing the RETURN key 

$L0 1,1 

DATE: 22-JUL-74 
TIME: 12:30 

$RUN CILUS 

CILUS V06-07 



CILUS prints the pound sign (#) when it is ready to accept a com- 
mand. If the system is configured for an RK system disk, mount the 
old RK system disk cartridge on RK unit 1. No special action is re- 
quired for an RF system disk. One of the CILUS commands shown below 
replaces the old CIL. 

DF:/NS:256:17/HO/BO/BL:nnn/TO:28<DK0:RSTS.LCL/LO (To RF system disk 

from RK) 

DKl:/NS:256:17/HO/BO/BL:nnn/TO:28<DK0:RSTS.LCL/LO (To RK system disk 

from RK) 



NOTE 

In place of nnn in the /BL:nnn switch, the 
user must type the size of the old RSTS 
CIL. The switch prevents CILUS from load- 
ing the new CIL if it is larger than the 
old CIL. 



If the system disk is an RFll disk, the CILUS command loads the 
CIL and then bootstraps the RSTS Initialization code into memory. The 
INIT code prints the system name followed by the OPTION query. 

The command to replace the CIL on an RK system disk mounted on 
unit 1 does not bootstrap the RSTS Initialization code. When the load 
operation is complete, CILUS reprints the pound sign (#) and waits 
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for another command. The system manager should exit from CILUS and 
terminate the DOS Monitor as shown below. 

#+C CONTROL/C exit from CILUS 

_^KI "KILL" required by DOS 

$PI Finish for an orderly exit 

TIME: HH:MM:SS 

DOS/BATCH V09-20 



The processor should be halted by moving the ENABLE/HALT switch 
to its HALT position. Dismount both cartridges and move the RSTS 
system disk to RK unit 0. When the disk is ready, write-enable the 
drive and bootstrap, the disk cartridge (see Section 3.2.1) to load 
the RSTS Initialization code into memory. 

When the Initialization code prints the OPTION query, the system 
manager must reinstall all published patches using the PATCH option 
of the Initialization code (see Section 3.3.5). The REFRESH option 
is not used since initializing a disk destroys any existing file 
structure. 

2.10 STRUCTURING THE SYSTEM DISK AND STARTING TIME SHARING 

2.10.1 Refreshing the System Disk 

To initialize the software structures on the system disk, the 
user must specify the REFRESH option. RSTS begins REFRESH with a 
safeguard question SURE, to which either a Y or YES answer should be 
given. If a Y answer is given, all subsequent refresh questions are 
printed in the short form indicated in the paragraphs below. If a 
YES answer is given, the subsequent questions are expanded to a long 
and more explanatory form. 

RSTS proceeds to interrogate the operator about specific infor- 
mation needed for disk refreshing. It asks first for the date and 
time (24-hour time) ; these must be supplied in the format which the 
question illustrates. 

RSTS asks (PACK?) for the system pack identification name and 
the system pack cluster size. The pack identification name is any 
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alphanumeric name from 1 to 6 characters in length without embedded 
spaces. This name is for internal use only and may be whatever the 
system manager wishes. The allowable pack cluster sizes are 1 or 2 . 
A cluster size of 1 allows more efficient usage of disk space but 
greater possible fragmentation of disk files (i.e., possible scatter- 
ing of file sectors randomly across the disk surface) . A cluster 
size of 2 maintains greater contiguity of file sectors (and hence 
fewer disk "seeks") but also allows greater possible waste of some 
disk sectors. For almost all installations, a system pack cluster 
size of 1 is recommended. The PACK question is answered by typing 
first the identification name, then a comma, and lastly the cluster 
size. For example, RSTS11,!*). 1 

RSTS next asks (MNGR?) for the Master File Directory (MFD) ac- 
count [1,1] password and cluster size. The password must be from 1 
to 6 alphanumeric characters with no embedded spaces. This password 
should be kept secret, as irresponsible access to the Master File 
Directory can destroy the software system. With tue restriction 
that the MFD cluster size cannot be less than the system pack cluster 
size, the MFD cluster size can be 1, 2, 4, 8, or 16. Large cluster 
sizes are more efficient with regard to minimizing disk seeks and 
minimizing directory accesses, but small cluster sizes are more effi- 
cient in using disk space. It is recommended that the MFD cluster 
size be made the same as the pack cluster size unless a large number 
of user accounts is required. The maximum number of user accounts 
possible is about 108 times the MFD clustersize. The MNGR question 
is answered by typing first the password, then a comma, and lastly 
the cluster size. For example, SECRET, 1*^ . 

RSTS then asks (LIBR?) for the System Library [1,2] password 
and cluster size. The same general principles apply here as in the 
n rscsdinc ^aracrra^h except that the cluster size micrht be somewhat 
larger, as it affects the number and size of the files to be stored 
under this account. A typical answer would be SYSLIB,4j?. 

RSTS next asks (SPACE?) for the number of disk blocks to be 
reserved in the Core Image Library to allow for possible future ex- 
pansion. A practical number is 10. RSTS adds the number of blocks 
specified by the system manager to the size of the CIL so that the 
CIL occupies extra space on the disk. 
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RSTS asks (BADS?) whether bad disk sectors are to be recorded. 
This question is included for compatibility with features planned 
for a future release of RSTS-11 and should at this time be answered 
with IGNORE J . 

RSTS asks (CR,OV,ER?) whether the CRASH. SYS file is to be cre- 
ated and whether the OVER. SYS and ERRM.SYS files are to be omitted. 
The CRASH. SYS crash-dump file, if created, occupies 28K words on the 
system disk and can be used by the system for recording (automatically 
or through operator intervention) an exact image of memory at the 
time of a system software failure; this is useful for reporting and 
analyzing system troubles which may unexpectedly appear. 

The OVER. SYS overlay file, if created, is a copy of the non- 
resident system overlay code (7K words in length) contained in the 
CIL on the system disk. If the system disk is an RF-type, there is no 
advantage in creating the OVER. SYS file, because the system can gain 
fast access to this overlay code in the CIL itself. But if the sys- 
tem disk is not an RF-type, then the OVER. SYS file must be created 
(so that it will be copied from the CIL on the system cartridge to 
the RC fast-access disk) . 

The ERRM.SYS error-message file, if created, is a copy of the 
error message file (2K words in length) in the CIL. There is no 
need on any RSTS-11 configuration to create the ERRM.SYS file, since 
the system has equally fast access to it in the CIL; if, however, the 
system manager wishes to modify the error message file or to access 
it on line, he should create it as the ERRM.SYS file. 

To create the CRASH. SYS file, answer the CR,OV,ER? question with 
Y; to omit it, answer with N. The OVER. SYS and ERRM.SYS files are 
created unless the answer to CR,OV,ER? specifically orders their 
omission. To omit the OVER. SYS file, follow the Y or N with a comma 
and an 0. To omit the ERRM.SYS file, do likewise with an E. Thus 

Y causes all three files to be created, 

Y,0 causes CRASH. SYS and ERRM.SYS to be created 
but OVER. SYS to be omitted, 

N,E causes only OVER. SYS to be created, and 

N,0,E causes all three to be omitted. 
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The following sample dialog shows an example of running 
REFRESH. 



(line a) OPTION? REFRESH 
(line b) SURE? YES 
(line c) DD-MON-YY? 10-DEC-74 
(line d) HH:MM? 19 = 55 

ID, CLUSTER SIZE? 



PACK,! 
MNGR , 1 

LIBR,4 



(line f) MANAGER PASSWORD, MFD CLUSTER? 

. (line g) LIBRARY PASSWORD, UFD CLUSTER? 

~ (line h) HOW MUCH EXPANSION SPACE DO YOU WANT IN YOUR CIL? 10 

(line i) BAD BLOCK FILE? IGNORE- 

(line j) CRASH.SYS (Y OR N), OVER. SYS (0), ERRM.SYS (E) FILES? Y,0,E 

(line k) RSTS V04B-17 SYS 104 TEST 
(line 1) OPTION? 

Lines a, b, and i apply to all configurations and installations. 
If, however, the YES answer at line b is shortened to Y, REFRESH 
prints all subsequent questions in the short form. The responses on 

date and 24-hour time. 

The question on line e can be answered with whatever name is 
desired as a pack identification label and with a 1 or 2 pack cluster 
size. The questions on lines f and g can be answered with whatever 
passwords are desired and with cluster sizes between a minimum of the 
pack cluster size and a maximum of 16. In both cases the cluster sizes 
indicated in the lines above are recommended for average installations. 

The answer to the question at line h determines the number of 
blocks to be added to the size of the Core Image Library. Ten blocks 
is an adequate number for almost all systems . Always type IGNORE in 
response to the question at line i. 



Line j can be answered in several ways. For most installations, 
the following table provides the recommended answer to the CR,OV,ER? 
question. 

Answers to CR,0V,ER? question 





system disk = 


= RF 


system disk = 


= RK 


Crash-dump file is 
desired 


Y,0,E 


Y 


No crash-dump file 
wanted 


N,0,E 




N 
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After the system manager answers the CR,OV,ER? question, RSTS 
proceeds to refresh the disk by building a brand new Master File 
Directory [1,1], system account, [0,1] and System Library Account [1,2], 
by creating the special files specified (CRASH. SYS, OVER. SYS, ERRM.SYS) , 
and by creating a fresh Storage Allocation Table (SATT.SYS) . 

After the disk has been refreshed, control returns to the begin- 
ning of the initialization code. RSTS prints its name on the termi- 
nal and asks again for an OPTION. The system manager must now start 
time sharing operations to build the system library as described in 
Section 2.10.2. 

2.10.2 RSTS Initialization 

The system manager initializes the system for time sharing opera- 
tions by using the START option. The following sample dialog shows 
the procedure. 

RSTS V4B-17 SYSTEM NAME 

OPTION? START (line a) 

DD-MON-YY? 10-DEC-74 (line b) 

HH:MM? 2^:15 (line c) 

RSTS11 - SYSTEM PACK MOUNTED (line d) 

ENABLE CRASH DUMP? Y (line e) 

CHAIN "INTT""" (line f) 

CATASTROPHIC ERROR (line g) 

PROGRAM LOST-SORRY (line h) 

I/O CHANNEL NOT OPEN (line i) 

READY (line j) 

CAN'T FIND FILE OR ACCOUNT (line k) 

READY (line 1) 

Lines a and j apply to all installations. At line a, the system 
manager types START to start time sharing operations. The message 
at line j indicates that RSTS has completed the necessary initializa- 
tion routines. 

At lines b and c, the system manager types the current date and 
time of day in the format indicated. RSTS then executes a series of 
initialization routines and prints the message shown at line d to 
announce that it has mounted the system disk. After printing line d, 

RSTS executes several more initialization routines. Apparent pauses 
are noticeable both before and after the system prints line d. 
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Line e does not appear unless the system manager created the 
crash dump file during the REFRESH option. If the file CRASH. SYS 
was created, RSTS asks whether the crash-dump facility is to be 
enabled. RSTS accepts a Y or N answer. If the crash-dump facility 
is enabled and any software failure occurs, an exact image of core 
at the time of the failure is written onto the disk file CRASH. SYS. 
If the crash-dump facility is not enabled, the system never writes 
anything onto the CRASH. SYS file. 

RSTS then concludes its initialization by printing out some 
messages whose meaning is not relevant here (lines f , g, h, and i) . 
RSTS attempts to run the System Library program INIT.BAS, which 
as yet does not exist on the system, and hence prints lines k and 1. 
After RSTS prints line 1, the console terminal is logged into the 
system under the System Library account [1,2]. The system manager 
should proceed immediately to build the system library as described 
in Section 2.11. 

For interpretation of initialization error messages, see Appen- 
dix E. 

2.11 BUILDING THE SYSTEM LIBRARY 

The source forms (.BAS) of the standard System Library programs 
are on the supplied medium labelled SYSTEM LIBRARY. This medium 
should be mounted and ready. Then all required and all optional 
System Library programs should be called into memory with the OLD 
command and COMPILEd onto disk. The required System Library programs 
with their protection codes are listed below: 

LOGIN <60> 

LOGOUT <6 rt > 

SYSTAT <168> 

TTYSET <168> 



REACT 


<60> 


INIT 


<60> 


UTILTY 


<60> 


ERRCPY 


<60> 


ERRDIS 


<60> 


ERRDI1 


<60> 


ERRORS 


<60> 
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The optional System Library programs together with their protection 
codes are the following: 

PIP <40> (compiled from PIP.BAS if system has Record 
I/O or from PIPX.BAS if system lacks Record 
I/O.) 

GRIPE <168> 
MONEY <40> 
SHUTUP <60> 
ODT <40> 
QUOLST <168> 
SYSCAT <60> 
VT5DPY <168> 
VT6DPY <168> 
ANALYS <168> 
RESEQ <40> 
EDIT <40> 
CONFIG 

The types of keyboard command sequences for building the System 
Library are the following. For protection code <60>: 

OLD DT0: LOGIN 

READY 

COMPILE 

READY 

For protection code <40>: 

OLD DT0:PIP 
READY 

COMPILE <40> 
READY 

For protection code <168>: 

OLD DT0:SYSTAT 

READY 

COMPILE 

READY 

NAME "SYSTAT.BAC" AS "SYSTAT .BAC<l68>" 

READY 
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The system prints READY after each command is executed. The 
commands show that the library files are read from the system library 
DECtape. 

The following sections show the exact procedure to follow for 
each distribution medium. 

2.11.1 DECtape Procedures 

To build the system library from DECtape, perform the following 
steps. 

Mount the DECtape, labelled DEC-11-ORTCB-A-UA, 
SYSTEM LIBRARY, on DECtape drive unit 0. 

Set the REMOTE/OFF/LOCAL switch on unit J2f to 
its REMOTE position. 

Set the WRITE ENABLE/WRITE LOCK switch on 
unit to its WRITE LOCK position. 

Type the commands to load the source programs 
into memory and compile them on the system disk. 
The following sample dialog shows the procedure. 

READY 

OLD DT0: LOGIN 

READY 

COMPILE 

READY 

OLD DT0: LOGOUT 

READY 

COMPILE 

READY 

OLD DT0:PIP (see footnote 1) 

READY 

COMPILE <H0> 

READY 



*If the Record I/O feature was not included in the generation of the 
system software, PIP.BAS cannot be used. In such cases PIPX.BAS must 
be used instead. The following would be the procedure: 

OLD DT0:PIPX 

READY 

COMPILE PIP<40> 

READY 



,,4- T, TTt 
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OLD DT0-.SYSTAT 

READY 

COMPILE 

READY 

NAME "SYSTAT.BAC" AS "SYSTAT.BAC<l68>" 

READY 

OLD DT0:TTYSET 

READY 

COMPILE 

READY 

NAME "TTYSET.BAC" AS "TTYSET .BAC<l68>" 

READY 

OLD DTjZf: GRIPE 

READY 

COMPILE 

READY 

NAME "GRIPE. BAC" AS "GRIPE. BAC<l68> " 

READY 

OLD DT0:INIT 

READY 

COMPILE 

READY 

OLD DT0: REACT 

READY 

COMPILE 

READY 

OLD DT0: MONEY 

READY 

COMPILE <40> 

READY 

OLD DT0:UTILTY 

READY 

COMPILE 

READY 

OLD DT0:SHUTUP 

READY 

COMPILE 

READY 

OLD DT0:ODT 

READY 

COMPILE <'i0> 

READY 
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OLD DT0:QUOLST 

READY 

COMPILE 

READY 

NAME "QUOLST.BAC" AS "QUOLST .BAC<l68>" 

READY 

OLD DT0:SYSCAT 

READY 

COMPILE 

READY 

OLD DT0:VT5DPY 

READY 

COMPILE 

READY 

NAME "VT5DPY.BAC" AS "VT5DPY .BAC<l68> " 

READY 

OLD DT0:VT6DPY 

COMPILE 

READY 

NAME "VT6DPY.BAC" AS "VT6DPY.BAC<l68> " 

READY 

OLD DT0:ANALYS 

READY 

COMPILE 

READY 

NAME "ANALYS.BAC" AS "ANALYS .BAC< 168>" 

READY 

OLD DT0:RESEQ 

READY 

COMPILE <40> 

READY 

OLD DT0:EDIT 

READY 

COMPILE <40> 

READY 

OLD DT0: CONFIG 

READY 

SAVE 

READY 
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OLD DT0:ERRDIS 

READY 

COMPILE 

READY 

OLD DT0:ERRDI1 

READY 

COMPILE 

READY 

OLD DT0:ERRCPY 

READY 

COMPILE 

READY 

OLD DT0: ERRORS 

READY 

COMPILE 

READY 

Proceed to Section 2.12 to establish the user accounts on the system 
disk. 

2.11.2 Magtape Procedure 

To build the system library from magtape, perform the following 
steps. 

Ensure that the write enable ring is removed from 
the reel labelled DEC-11-ORTBB-A-MC9 , SYSTEM GEN- 
ERATION AND LIBRARY (for 9-track) or DEC-11-ORTBB- 
A-MC7, SYSTEM GENERATION AND LIBRARY (for 7 -track) . 

Mount this tape on unit jZf. Ensure that no other 
drive is on 0. 
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Ensure that the FILE PROT indicator is on. 

Position the tape at its load point. (The LD PT 
indicator comes on.) 

Set the ON-LINE/OFF-LINE switch to its ON-LINE 
position. Ensure that the READY indicator comes 
on. 

Type the commands shown in Section 2=11,1 except 
replace the device designator DT0: with MT0: to 
load the source programs from the magtape. (It 
is assumed that the system console terminal is 
still logged into the system under account [1,2]. 
The programs are stored under account [1,2] on 
the magtape.) These commands load the source 
programs into memory and compile them on the 
system disk. 

After compiling all the programs, proceed to Sec- 
tion 2.12 to create the user accounts on the sys- 
tem disk. 

2.11.3 RK05 Disk Cartridge Procedures 

the following steps. 

Place the distribution disk cartridge labelled 
DEC-11-ORPTB-A-HA, SYSTEM LIBRARY, in RK05 drive 

unit 1. 

Set the unit to RUN and WRITE ENABLE. 

At the system console terminal, type the follow- 
ing commands to mount the disk. (The system 
prints the READY messages.) 

S$ = MID(SYS(CHR$(6)+CHR$(-10)+"SYSLIB") ,7,4) 

READY 

M$ = S'* ^ . t '/r:Hn*/'fiU^HT^tf^U^Hnt('c(^J.clDn^^;4/'^^J.<;t4. 

SPACES ( 12 )+"DK"+CHR$(l)+CHR$(-l)) 
READY 

If any errors occur, ensure that the drive unit is READY and is write 
enabled. Also, ensure that each line of the commands is exactly cor- 
rect. If a command contains an error, retype the entire command. For 
information on editing BASIC-PLUS commands, see Sections 2.2.3, 3.3, 

and 3.6 of the RSTS-11 System User's Guide. 
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After the disk is logically mounted on unit 1, 
type the commands shown in Section 2.11.1 ex- 
cept replace the device designator DT0: with 
DK1 : to load the source programs from the car- 
tridge. (It is assumed that the system console 
terminal is still logged into the system under 
account [1,2]. The programs are stored under 
account [1,2] on the disk.) These commands 
load the source programs into memory and com- 
pile them on the system disk. 

After compiling all the programs, proceed to 
Section 2.12 to create the user accounts on 
the system disk. 

2.12 CREATING ASCII TEXT AND MESSAGE FILES 

After the system manager builds the system library programs , he 
must run the PIP system program to print sample ASCII files and to 
create text and message files. 

2.12.1 Creating System Message Files 

Two standard message files, HELP. TXT and NOTICE.TXT, would normally 
be established on the disk under the System Library account [1,2]. If 
these files are present on the disk, the system uses them; if they are 
not present, the system proceeds without them. 

The HELP. TXT file is printed out on a user's terminal by the LOGIN 
program whenever a user types HELP before logging in. The intent is 
to inform the potential user of general information on obtaining an 
account, on using the system, or on logging into the system. 

The system program LOGIN prints the NOTICE.TXT file on a user's 
terminal whenever he successfully logs into the system. NOTICE.TXT 
serves as a convenient means by which the system manager can inform 
users of recent developments, regulations, procedures, and notices. 

On the distribution medium are samples of the NOTICE.TXT and 
HELP. TXT files which may be examined to see what the typical content 
of these files is. The system library PIP program may be used to 
create original files from keyboard input (as in the example of 
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NQTICE.TXT below) or to co nu the samples from the distribution medii 
(as in the example of HELP. TXT below) . 

RUN PIP 

PIP - RSTS V04B-17 SYSTEM TEST 

#HELP ,TXT<DT0 : HELP . TXT/FA 

#NOTICE.TXT<KB:/FA 

WELCOME TO RSTS-11 . 

PLEASE REPORT ANY PROBLEMS BY RUNNING $GRIPE. 

) 

+ Z 

(Replace DT0: with either MTJJ: for magtape medium or DK1: for disk 
cartridge. ) 

2.12.2 Creating Control Files for INIT 



wnenever tne system is restarted, tne initialization code logs in 
the console terminal (KB0:) under account [1,2] and attempts to run 
the System Library program INIT. If INIT is begun after a normal sys- 
tem start (because the system was bootstrapped from disk) , INIT uses 
the System Library file START. CTL to determine which actions it should 
perform. If INIT is begun after a system crash, it does not look at 
START. CTL but rather at CRASH. CTL (which is also a System Library file) 
to determine what it must do. 

There are five types of commands which may appear in the control 
files; see Chapter 5 for details. The last command in each control 
file should be BYE, which directs INIT to log out, thus releasing the 
console terminal from account [1,2] or should be END if INIT runs a 
program such as ERRCPY which detaches from the console terminal. If 

does not have the BYE command, then after a system restart the console 
terminal remains logged into the system under the System Library ac- 
count [1,2] . 

The START. CTL and CRASH. CTL files may be created from keyboard 
input by running the System Library program PIP. Sample control files 
are shown below. These files are created from keyboard input through 
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the System Library program PIP. The following sample dialogue illus- 
trates how this is done. 



RUN PIP 

PIP - RSTS V0UB-17 SYSTEM TEST 

#START.CTL<KB:/FA 

LOGINS 

SEND RSTS-11 IS NOW ON THE AIR ... I 

FORCE KB9: + SET LA30S 

FORCE KB4: +SET VT06 

FORCE KB0: RUN $ERRCPY 

END 

+ Z 

#CRASH.CTL<KB:/FA 

LOGINS 

SEND RSTS-11 RECOVERED FROM A CRASH 



+ SET LA30S 
+SET VT06 
[1,5] 
RUN $ANALYS 
[0,1] CRASH. SYS 
KB: 
BYE 
YES 
RUN $ERRCPY 



FORCE KB9 
FORCE KBU 
LOGIN KB1 
FORCE KB1 
FORCE KB1 
FORCE KB1 
FORCE KB1 
FORCE KB1 
FORCE KB0 
END 

+z 

# + Z 

READY 

2.12.3 Establishing the User Accounts on the System Disk 

At refresh time, only accounts [0,1], [1,1], and [1,2] are cre- 
ated. No user accounts as yet exist. User accounts can be created one 
by one through the System Library program REACT, or a whole set of 
standard user accounts can be created by giving REACT a single com- 
mand, STANDARD. In the latter case, REACT accesses a disk file named 
ACCT.SYS under the System Library account. Obviously, this file must 
be created before running REACT. A sample ACCT.SYS file is supplied 
on the distribution medium. The ACCT.SYS file can be created by the 
System Library program PIP operating from keyboard input. The 
ACCT.SYS file is an ASCII file, each line of which is formatted as 
follows : 

project #, programmer #, password, disk quota, cluster 
size, additional identification 
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The disk quota is the number of disk sectors which the account is 
allowed to keep when logging out. A quota of means no quota; 
i.e., that the account has no disk limit and can keep at logout all 
disk sectors claimed. The cluster size cannot be less than the pack 
cluster size; except for this restriction, the cluster size can 
be 1, 2, 4, 8, or 16; a cluster size of indicates a default to the 
pack cluster size. Large cluster sizes permit very large files 
and/or very large numbers of files under the account but tend to 
waste disk space. Small cluster sizes ensure economy of disk space 
but tend to demand more disk accesses. Cluster sizes of 1, 2, or 4 
are recommended for most systems. The additional identification 
field is not used by REACT but is printed out by the System Library 
program GRIPE. Sample lines in the ACCT.SYS file might be the fol- 
lowing: 

1, 5, GGG,0,1, PRIVILEGED ACCOUNT 

40, 40, WLS, 0,2, WILLI AM SMITH — ACCOUNTING 

50,56,JJMRTN,0,4 ,JOHN MARTIN — ENGINEERING 

100, 100, DEMO, 100,1, GENERAL DEMONSTRATION ACCOUNT 

The following dialogue illustrates how the ACCT.SYS file can be 
created from keyboard input through PIP (which is assumed to be still 
running from the example above) . 

#ACCT.SYS<KB-:/FA 

1, 5, GGG, 0,1, PRIVILEGED ACCOUNT 

iJ0, 40, WLS, 200, 2, WILLIAM SMITH — ACCOUNTING 

50,56,JMRTN,500, I l,JOHN MARTIN — ENGINEERING 

100, 100, DEMO ,100,1, GENERAL DEMONSTRATION ACCOUNT 

+Z 

#+Z 

READY 

After the ACCT.SYS file has been created, REACT should be run to 
establish the STANDARD accounts. The dialogue for this is as follows: 

RUN REACT 

'REACT' SYSTEM ACCOUNT MANAGER 

FUNCTION? STANDARD 

ALL ACCOUNTS IN '$ACCT.SYS' ARE NOW ENTERED 
FUNCTION? +C 

READY 
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2.12.4 Removing the System Library Distribution Medium 

After creating the ASCII files and establishing the user accounts 
on the system disk, the system manager should store the distribution 
medium and all copies and related listings in a safe place. If the 
distribution medium is disk cartridge, the system manager must logi- 
cally dismount the system library disk cartridge as shown below. 

RUN $UTILTY 

'UTILTY' SYSTEM UTILITY PROGRAM 

£DISMOUNT DK1: 

#+C 

READY 

2.12.5 Determining Remote Line Characteristics 

At installations using remote hardware, specific lines of the 
DC11 or DL11E may be devoted to terminals that are not ASR33 compatible. 
The CONFIG system program would be run at this point in the system 
generation to permanently set the characteristics of those lines that 
are not ASR33 compatible. CONFIG modifies the RSTS-11 Monitor tables 
so that the default characteristics set up for a remote line are 
recognized every time the Dataset is answered by RSTS. See Chapter 5 
for instructions on running the system program CONFIG. 

2.12.6 Suggestions for Operation and Test 

After the system disk is built, it is suggested that the user 
shut the system down as described in Section 5.2 and restart it to 
test the new START. CTL file. The user can also run DSKINT to initial- 
ize private disks or can run ROLLIN to create a back up image of an 
entire disk. 
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CHAPTER 3 
HALT, START AND RESTART PROCEDURES 

This chapter describes orderly halt, start, and restart/ 
recovery procedures (which occur in case of catastrophic error or 
system crash). The chapter is divided into four sections. Section 3.1 
explains what an orderly halt is and what the dangers of a disorderly 
halt are and how to circumvent the unwanted results of a disorderly 
halt. Section 3.2 discusses the multiple ways of booting RSTS-11 
initialization code back into core after the system has been initial- 
ized, running, and halted in such a way that operator start action 
is required. Section 3.3 explains the starting options available 
once RSTS-11 initialization code has been booted back into core. 
Section 3.4 explains the various causes of catastrophic errors and 
system crashes and the conditions which allow for automatic recovery 
and restart. 

3.1 HALTING RSTS-11 

RSTS-11 may be halted in an orderly fashion by running the 
System Library program SHUTUP. The program warns users that the 
system is about to be halted, ensures that all users log out, dis- 
mounts non-system disks, and brings the CPU to a halt at address 54. 
As a result, all files are properly closed and system accounting 
information is accurately updated . The halt leaves the program 
counter loaded in such fashion that depressing the CONTinue switch 
causes the system to be re-booted into core from its core-image 
library in the CORE. SYS file. 

If RSTS-11 is halted by manually moving the HALT/ENABLE switch 
to its HALT position, clean-up operations as described above are 
not performed. As a result a disk storage allocation table and/or 
file directories are left in an obsolete state, file data can 
consequently become corrupted, and accounting information may be 
lost. The only way to recover from such a disorderly halt and to 
salvage possible vital file information is to raise the HALT/ENABLE 
switch back to its ENABLE position before any other action is taken, 
to depress the CONTinue switch, and thereby to return RSTS to the 
state in which it was before the HALT switch was used. 
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3.2 STARTING RSTS-11: BOOTING RSTS INTO CORE 

RSTS is (re-) started by (re-) booting its initialization code into 
core from disk (or from the CIL DECtape) . (The RSTS-11 initialization 
code is once-only code, loaded into high core and overlaid after 
its execution by the users ' compiled programs . ) 

To (re-) boot the initialization code into core, several pro- 
cedures are possible. They are described in the following para- 
graphs . 

3.2.1 Booting RSTS from the System Disk Through the ROM Bootstrap 

(a) Make sure that the system disk is mounted on disk unit #0. 

(This statement is not applicable if the system disk is an 
RF disk.) 

(b) Make sure that the system disk is READY and WRITE-ENABLED . 

(c) Move the CPU's HALT/ENABLE switch into its HALT position. 
Then raise it back into its ENABLE position. 

(d) Set the CPU's Switch Register to 173100 . 

(e) Depress the LOAD ADDRESS switch; it returns automatically. 

(f) Set the CPU's Switch Register to 

177406 if the system disk is on RK disk unit #0. 

or 
177462 if the system disk is an RF disk. 

(g) Make sure that the console Teletype is on line. 

(h) Depress the CPU's START switch; it returns automatically. 

This causes RSTS-11 to be booted from the disk's CORE. SYS file into 
core, to branch immediately to its initialization code, and con- 
sequently to print on the console Teletype the system name and re- 
quest an "OPTION?" (See section 3.3.) 

This method of bootstrapping is independent of any previous 
contents of core and requires only that the system image be the 
first Core Image module in the system disk's CIL (CORE. SYS) and that 
a special bootstrap routine reside on sector #0 of the system disk. 
(These requirements are common to all methods of bootstrapping RSTS 
into core from disk and their fulfillment is ensured by the action 
taken by the RSTS-11 system itself when the system is first booted 
in from the CIL DECtape.) (See section 2.2.10.) 
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3.2.2 Re-Booting RSTS from the System Disk After a System Halt 

After the SHUTUP program has brought RSTS to an orderly halt 
at address 54 or after a catastrophic error or system crash (see 
section 3.4.1) has halted RSTS at address 54, RSTS can be re-booted 
into core from the system disk in one of three ways . 

3.2.2.1 Pressing the CONTinue Switch with Sw itch Register Not Set 
to 177777 — 

If a system halts at address 54 and the CPU's Switch Register 
is not set to 177777, the operator depresses the CPU's CONTinue 
switch and control branches to an in-core loader. RSTS is re-booted 
from the disk into core in normal start-up mode. Control jumps to 
the initialization code, which prints the system name on the console 
Teletype and asks for an OPTION?. (See section 3.3.) The exact 
procedure to be followed for this is as follows: 

(a) Check to make sure that the RUN light is off. (If the 
RUN light is lit, the system has not halted.) 

(b) Be sure that the CPU's HALT/ENABLE switch is set to ENABLE. 

(c) Make sure that the CPU's Switch Register is not set to 
177777. 

(d) Depress the CONTinue switch; it returns automatically. 

It may be noted that starting the system from address 50 after 
a halt will produce exactly the same results as depressing the CONT- 
inue switch. 



3-2.2.2 Pressing the CONTinue Swit ch with Switch Register Set to 
177777 ~ 

If a system halts at address 54, the same procedures as de- 
scribed above in section 3.2.2.1 can be followed; but, at step (c) 
the CPU's Switch Register must be set to 177777. Control branches 
to the in-core loader and RSTS is booted into core in a special 
autorestart mode. See section 3.4.4. 

3.2.2.3 Starting at Address 52 with Switch Register Set to 177777 

If the system is re-started from address 52 after a system 
halt at address 54, three possibilities exist. 
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(1) If the crash-dump facility was not enabled at the previous 
system START-up, then (regardless of how the Switch Reg- 
ister is set) the system will immediately halt again at 
address 54 . 

(2) If the crash-dump facility was enabled at the last system 
START-up but, after starting from address 52, the system., 
finds the CPU's Switch Register set to something other 
than 177777, then the system will immediately halt again 
at address 54 . 

(3) If the crash-dump facility was enabled and if after starting 
from address 52 the system finds the CPU's Switch Register 
set to 177777, then the system first writes the contents 

of all of core onto the CRASH. SYS file and, after com- 
pletion of this writing, proceeds immediately to the in- 
core loader routine, causing RSTS to be re-booted into 
core from the system disk in the special autorestart mode 
described in section 3.4.4. 

Clearly, the third possibility is the only meaningful one. The pro- 
cedures for the third possibility are as follows: 

(X) (_neCK. to HldKe suie i_iia.i_ one £<.L/li ±j.i)m- ->-*■• wj-j- . 

(2) Be sure that the CPU's HALT/ENABLE switch is set to ENABLE. 

(3) Set the CPU's Switch Register to 52. 

(4) Depress the LOAD ADDRESS switch on the CPU panel. 

(5) Set the CPU's Switch Register to 177777. 

(6) Depress the CPU's START switch; it returns automatically. 

3.2.3 Booting RSTS from the System Disk Through the Stand-Alone 
Program ROLLIN 

If the stand-alone program ROLLIN is in core rather than RSTS, 
and, if the RSTS system disk is mounted, ready, and write-enabled, 
then RSTS can be booted into core by giving ROLLIN the command 
#/BOOT:DF (if the system disk is an RF disk) 

or 
#/BOOT:DK (if the system disk is on RK cartridge drive 
#0) • 



r* v-il J .. £ 

Dec unajJuci u. 



After RSTS has been booted into core, it will commence with 
the initialization routines, printing the system name on the console 
Teletype and requesting an OPTION?. See section 3.3. 
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3.2.4 Booting RSTS from CIL DECtape Through ROM Bootstrap 

RSTS can be booted into core from the preserved CIL DECtape 
through the ROM bootstrap by following the procedures indicated in 
section 2.3.14. Note, however, (as described in section 2.2.10) 
that this not only boots RSTS into core from DECtape but also loads 
the entire CIL from DECtape onto the system disk and then re-boots 
RSTS (which is the first core image on the disk CIL) from disk into 
core. This procedure can be used to restore the CIL to the disk in 
case some operational error has corrupted it. 

3.3 STARTING RSTS-11: STARTING OPTION 

Whenever RSTS is (re-) booted into core in such fashion as to 
take the normal start-up mode, control always jumps to the beginning 
of the initialization code and the system asks for an OPTION?. At 
this point, the operator must type in on the console keyboard one of 
the valid options listed below: 

Options at Start-up time 



long form of operator 
response 



START 



REFRESH 



LOAD 



BOOT 



short form of operator 
response 



or LINE FEED 



If anything other than a valid option is typed by the operator, 
the system rejects it, prints the valid options, and again requests 
an "OPTION?". If the operator types a valid option, the system 
proceeds according to the details explained below. 

3.3.1 Normal System START-up Option 

If the operator responds to OPTION? with START or LINE FEED, the 
system executes its normal initialization code, which, after inter- 
rogating the operator, puts RSTS into its full running state. The 
dialogue involved in this option appears in the following format: 
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RSTS V4A-12 SYSTEM #213 

OPTION? START (line a) 

DD-MON-YY? ll-AUG-72 (line b) 

HH:MM? 15:14 (line c) 

V4A12 - SYSTEM PACK MOUNTED (line d) 

ENABLE CRASH DUMP? YES ' (line e) 

CHAIN "INIT" (line f) 

CATASTROPHIC ERROR (line g) 

PROGRAM LOST-SORRY (line h) 

READY dine i) 

SYSTEM INITIALIZATION PROGRAM (line j) 

BYE$FAST$ (line k) 

READY • (line 1) 

CONFIRM: SAVED ALL DISK FILES; 701 BLOCKS IN USE (line m) 
JOB 1 USER 1,2 LOGGED OFF KB0 AT ll-AUG-72 03 :14 PM 
SYSTEM RSTS VlA-12 SYSTEM #213 
RUN TIME WAS .5 SECONDS 
ELAPSED TIME WAS 19 SECONDS 
GOOD AFTERNOON 

Lines a and j are the same for all installations. The questions 
on lines b and c are answered according to the current date and time. 
Pauses occur before and after line d is printed when the system 
executes several initialization routines. 

Line e does not appear unless the crash-dump file CRASH. SYS 
was created at disk Refresh time. (See sections 2.3.15 and 2.2.12.) 
Answering Y to the question at line e enables the crash-dump facility; 
answering N disables it; the enabled or disabled condition prevails 
until the next system start-up. (See section 3.4.3.) 

Lines g, h, and i have no real significance to the operator 
in this context: They are caused by a deliberate system error- 
simulation in order to take advantage of standard error-handling 
routines which effect a clean initialization of Job 1 on KBJ3: 
under account [1,2] . 

The initialization code also forces a CHAIN INIT statement 
into Job l's keyboard input buffer. This is pre-echoed as line f 
and causes Job 1 to begin running the System Library program INIT. 
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The INIT program name is printed at line j , performs the opera- 
tions which the START. CTL file (see Section 5.1) directs it to do, 
and exits back to the System Monitor upon executing its own END state- 
ment. The exit to the system Monitor causes the READY at line 1. 

If the START. CTL file contains a BYE command, the INIT program 
forces the character-string "BYE<ALT>FAST<ALT>" into the Job 1 key- 
board input buffer before exiting back to the System Monitor. This 
echoes as line k. When the System Monitor detects this string in the 
input buffer, it causes the console terminal (KB0:) to be logged off 
from account [1,2] and causes the print-out at lines m and following. 
If the START. CTL file contains no BYE command, the console terminal 
remains logged in under account [1,2] and lines k, m, and following 
do not appear. In either case the RSTS-11 system is fully initialized 
and running. 

At this point the operator must decide whether the automatic 
restart facility is to be enabled or to be left disabled. (See 
Section 3.4.3.) If the automatic restart facility is to be enabled, 
the CPU's Switch Register must be set to 177777; (i.e., all switches 
in the up position) ; the automatic restart facility remains enabled 
as long as the CPU's Switch Register remains set to 177777. If a 
Switch Register toggle between positions 15 and is set down to its 
position, the automatic restart facility is disabled for the duration 
of this condition. 

3.3.2 Disk-REFRESHment Option 

The OPTION question should be answered with REFRESH or R only if 
the system-disk structure is to be completely rebuilt from scratch. 
If this option is chosen, all accounts and all files existing on the 
public disk structure are lost. 

The details of disk refreshment are explained in section 2.10.1. 
All of those details are directly applicable here. One further 
option, however, exists for the case where an already structured 
RSTS system disk is to be refreshed. If the SURE question is 
answered with (for old) rather than with Y or YES, then the disk- 
refreshing routine asks the operator only for the date and time and 
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extracts from the pre-existing system disk the answers which it needs 
for the questions (which therefore are not printed out on the 
terminal) . As a result, the refreshed disk is built anew with a 
fresh CRASH. SYS file only if a CRASH. SYS file existed previously on 
that disk, with a fresh OVER. SYS file only if an OVER. SYS file existed 
previously on that disk, and with a fresh ERRM.SYS file only if an 
ERRM.SYS file existed previously on that disk. Similarly, the 
refreshed disk is given the same pack identification label, the same 
[1,1] password, the same [1,2] password, and the same respective 
cluster sizes as it had before. The BAD. SYS file (reserved for 
future system implementation) contains the same information which it 
contained previously. 

An alternative exists to the above-described all-inclusive 
use of the O (old) answer. Instead of answering the SURE? question 
with O, the SURE question can be answered with Y or YES. The system 
then proceeds to ask the operator all the individual questions 
described in Section 2.10.1. For any individual answer, however, 
can be typed in on the keyboard. This causes the system to fetch 
the answer for that individual question from the pre-existing 
system-disk structure. 

At the conclusion of disk-refreshment, control returns to the 
beginning of the initialization code, and the OPTION? question is 
again asked. 

3.3.3 LOAD Option 

If the initialization code OPTION? question is answered with 
LOAD or L, then the system asks for the name of the program to be 
loaded from the CIL (LOAD PROGRAM) . The operator then types in the 
name of one of the programs optionally included at the end of the 
CIL (see Section 2.7.18). 

Upon reception of the operator's response, the system searches 
the disk for the desired program and loads it into memory and starts 
its execution. (See Chapter 6 for details on DSKINT and ROLLIN 
and note that LOADing either of these programs into memory 
overlays the RSTS Monitor.) If the system cannot find the requested 
program in the disk's CIL, it prints the message PROGRAM NOT FOUND 
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and then returns to the OPTION question at the beginning of the 
initialization code. 

3.3.4 BOOT Option 

If the OPTION question is answered with BOOT or B, the system 
asks from what device (BOOT DEVICE:) a program is to be bootstrapped. 
The operator must then type in a device- type; see the table below. 



Operator's response to 
BOOT DEVICE: 


Device from which a program 
is bootstrapped into core 


DF 


RF11/RS11 disk 


DK 


RK disk cartridge drive #0 


DC 


RC11/RS64 disk 


DP 


RP disk pack drive #0 


DT 


DECtape drive #0 


MT 


Magtape drive #0 



Upon receiving the operator's response, the subsequent code determines 
whether the indicated device exists on the system. If it does not 
exist, an error message NOT A VALID DEVICE will be reported. If the 
device does exist, the system branches to the proper internal 
bootstrap code, which reads the first 64 words from block #0 on the 
device into the first 64 words of memory and transfers control to 
address 0. By this means, for example, the DOS Monitor could be 
bootstrapped into memory from its disk (and overlay the RSTS Monitor) . 

3.3.5 PATCH Option 

The RSTS Initialization code PATCH option provides a convenient 
means for altering the RSTS system code as errors are found and cor- 
rections are published. When a RSTS system generation is performed, 
all patches are installed immediately after the Core Image Library 
(CIL) is loaded onto the system disk. This is necessary since patches 
may affect the initialization code used to build required file 
structures, create the system files, and set up tables used during 
normal timesharing. Patches are published in the RSTS Installation 
Notes if problems are uncovered after a "code freeze", but before a 
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new release is available from Digital's Software Distribution Center. 
Thereafter, patches are published in the DIGITAL Software News. 

The PATCH option makes permanent changes to the RSTS CIL on 
the system disk. The CIL is made up of several modules including 
SY (the resident monitor and device drivers) , OV (Overlay Code) and 
ER (error messages) . Any of these modules may be altered using the 
PATCH option. 

Patches take many different forms. Some are in-place patches to 
one or more words in one or more modules. Others require patch 
space in the affected modules. In some cases, patches affect fixed 
addresses and are straightforward; however in most cases it is 
necessary to refer to the system load map to find the addresses of 
affected sections. Published patches describe the procedures required 
to make the alteration correctly. 

The PATCH option is called by typing PATCH or simply P in 
response to the initialization code OPTION query. PATCH replies by 
asking for a MODULE NAME (one of the three listed above) , a BASE 
address, and an OFFSET address. The module name determines the CIL 
module to be changed. The response "SY" indicates that the patch 
applies to the resident monitor. The base address further determines 
the actual locations to be patched. For example, the base address 
for the PRINT USING section of BASIC-PLUS is found in the load map 
and might be entered as the response to the BASE query. Finally, 
the offset address is the first location to be changed relative to 
the specified base. For example, a PRINT-USING patch may begin at 
an offset of 100 octal bytes from the beginning of Print Using. 
After these items are entered, PATCH prints the old contents of the 
specified location and opens the word for change. PATCH opens and 
changes .successive locations depending on the user responses. 

Details for the use of the patch option are included in the 
example presented below. 
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SY 


122722 


000000 


0000001 


SY 


122722 


000002 


000000? 


SY 


122722 


000004 


000000? 


SY 


122722 


000006 


000000? 


SY 


122722 


000010 


000000? 


SY 


122722 


000012 


000000? 



RSTS V04B-17 SYS 104 TEST 

OPTION? PATCH 

MODULE NAME? SY 

BASE? 122722 

OFFSET? 

MODULE BASE OFFSET OLD NEW 

~T6Tl5 

14 

11561 

177776 

207 
___________ +c 

RSTS V04B-17 SYS 104 TEST 

OPTION? BOOT 
BOOT DEVICE: DF 

RSTS V04B-17 SYS 104 TEST 

OPTION? 

All numbers printed by the PATCH option and all numeric responses 
are octal. In the example, the number 122722 indicates an address 
found in a load map or computed. PATCH does not perform any 
arithmetic; hence, expressions of the form [NAME] + 2,0 must be 
manually calculated using 2's complement arithmetic. (If unfamiliar 
with the octal representation of binary numbers or with 2's complement 
arithmetic, consult a Software Support Representative.) As PATCH 
opens successive locations, it prints the current or old location 
contents and waits for new data to be entered as an octal word. A 
carriage return (CR) is used to enter the new data. PATCH then 
sequences to the next location. A line feed <LF> with no new data 
causes PATCH to sequence to the next location without altering the 
current location. PATCH continues to open successive locations 
until the CONTROL/C combination is typed. CTRL/C returns to the 
initialization code OPTION query. 

Note that changes are made immediately upon typing the carriage 
return key. If an error is made it becomes necessary to reenter the 
PATCH option to correct the mistake. Printing the old contents of a 
location provides a check for proper placement of a patch. If the 
old contents of any location shown in a published patch are not iden- 
tical to those printed by the PATCH option, all locations should be 
restored to their old contents. This may indicate an error in the use 
of load maps or an error in the published patch itself. Finally, a 
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complete patch may be double checked by reentering the PATCH option 
and using the line feed key to examine successive locations. 

NOTE 

Whenever the user patches the 
Resident Monitor (module SY) , 
he must use the BOOT option 
to load the patched version 
from disk into memory. 

3.4 AUTOMATIC RECOVERY AND RESTART FACILITIES FOR HANDLING 
CATASTROPHIC ERRORS AND SYSTEM CRASHES " 

3.4.1 Nature and Causes of Catastrophic Errors and System Crashes 

A catastrophic error or a system crash is an error-trap to 
vector 4 or vector 10. (See section on Processor Traps in PDP-11/20 
Processor Handbook 2.2.4 or in PDP11/45 Processor Handbook 2.7. See 
Section 3.4.2 below for distinction between catastrophic error and 
system crash.) Such traps can be caused, for example, by referencing 
a nonexistent (or non-responding) Unibus address (bus time-out trap) , 
by referencing an odd address with an instruction that requires a 
word-address, or by attempting to execute a reserved or nonexistent 
instruction. 
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Catastrophic errors and system crashes can therefore be due to 
any of four types of problems: (a) configuration errors, 
(b) privileged-account programming errors, (c) hardware malfunctions, 
and (d) system software deficiencies. Each of these is discussed 
individually below. 

3.4.1.1 Configuration Errors - If the software configuration and 
the hardware configuration do not correspond exactly, bus time-out 
traps occur whenever the software attempts to address a peripheral 
interface which, for the software, logically exists but which for 
the hardware, does not physically exist. Thus at system-generation 
time, it is imperative that the operator respond to SYSGEN's questions 
about peripherals with answers which accurately describe the existing 
hardware configuration. 

3.4.1.2 Privileged-Account Programming Errors - The RSTS system 
software is designed to protect itself against programming errors 
perpetrated under non-privileged accounts. The system itself, upon 
detecting such an error, aborts execution of the would-be error 
and reports a corresponding error message to the guilty user. 

The RSTS software is vulnerable to certain types of errors 
perpetrated under privileged accounts. By intent and design, the 
system manager (and those to whom he assigns any [1,*] account) 
have been given extensive powers which are not available under non- 
privileged accounts. These powers allow privileged users to modify 
System Library programs or to create utility programs in such fashion 
that they can access and modify any part of core. Extreme care must 
be used when programming with privileged SYS functions. A mistake 
can cause the system to take an error trap. 

3.4.1.3 Hardware Malfunctions - Hardware malfunctions can be 
responsible for crashing the system. If unexplainable and random- 
type system crashes or catastrophic errors occur (particularly on 
systems which hitherto have 
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been functioning well) , it is likely that a hardware problem has ' 
arisen. In such cases a DEC Field Service Representative should be 
contacted. 

3.4.1.4 System Software Deficiencies 

Although every attempt has been made to detect and eliminate 
system software bugs, the paths and routes which control can take 
through the RSTS software are incalculably numerous. It is possible 
that, given certain conditions and certain sequences, the RSTS soft- 
ware can trap to vector 4 or vector 10. If a problem of this type 
is discovered (it should be reproducible in a defined environment 
and under defined conditions) , a DEC Software Specialist should be 
contacted. If new problems of this type become known, DEC reports 
them in The Digital Software News. (Known problems are reported in 
Chapter 7 . ) 

3.4.2 Automatic Recovery from Catastrophic Errors 

At system-generation time, SYSGEN asks whether the module 
for automatic recovery from catastrophic errors is to be included 
in the system. If a Y answer is given, the system is configured with 
the NF (No-Fail) module; otherwise the system is configured without it. 

If the system is configured with the No-Fail module, then 
whenever a trap occurs to vector 4 or vector 10, the system distin- 
guishes the trap as one of two categories: it is either (a) a cata- 
strophic error for which one particular user is responsible or 
(b) a system crash for which some Monitor bug is possibly responsible. 
If the system is configured without the No-Fail option, this distinc- 
tion is not made; instead all traps to vectors 4 or 10 are treated 
as system crashes, regardless of their true cause. The handling of 
system crashes is treated below in section 3.4.3. The handling of 
catastrophic errors by the No-Fail code is as follows. 

The system determines which user was responsible for the 
error-trap. It flags that user's job with a special code which will 
cause the system to reinitialize that user's job area completely 
when it is next his turn to run. The system prints out on that 

user's terminal the message CATASTROPHIC ERROR PROGRAM LOST-SORRY. 
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At this point the system determines whether the crash-dump 
facility was enabled at system START-up time (which is possible only 
when the system has the CRASH. SYS file created at system-disk Refresh- 
time) . If the crash-dump facility was enabled, the system copies 
the contents of core onto the CRASH. SYS file and resumes normal time- 
sharing operations. If, on the other hand, the crash-dump facility 
was not enabled, the system resumes its normal time-sharing operations. 
The reinitialized user is in the same state as he would be if he had 
just logged in and received the NEW OR OLD question. 

A single catastrophic error does not affect any user other than 
the one whom the system considers guilty, and does not halt the system. 
If, however, two catastrophic errors occur within the same minute 
(more accurately stated, two error-traps within the same minute), the 
system halts at address 54. This protects the system against an in- 
finite loop of error-traps should they be caused by some repeating 
hardware malfunction. 

See Appendix F for a flow-chart portraying the design of the 
No-Fail automatic recovery process. 

3.4.3 Automatic Restart after System Crashes 

If a system crash is distinguished by the No-Fail code (see 
section 3.4.2) or if any error-trap occurs in a system configured 
without the No-Fail code, the system takes an automatic restart 
path only if both of two conditions are fulfilled: 

(a) the crash-dump facility must have been enabled at 
system START-up time (possible only when the CRASH. SYS 
file exists) and 

(b) the CPU's Switch Register must currently be set to 
177777 . 

If either condition is not fulfilled (or if both are not fulfilled) , 

the system does not take the automatic restart path but simply halts 

at address 54- 

If the system halts at address 54, the operator may choose one 
of three procedures . 

(a) He depresses the CPU's CONTinue switch, which causes 
the system to be re-booted into normal system start-up 
mode. 
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(b) He sets the CPU's Switch Register to 177777 and depresses 
the CPU's CONTinue switch, this causes the system to be 
re-booted from disk and to be started in the special 
autorestart mode described below. 

(c) Finally, the operator starts the CPU at address 52 with 
CPU's Switch Register set to 177777 (see section 3.2.2.3). 
This causes the system first to write the contents of 
core onto the CRASH. SYS file (provided the crash-dump 
facility had been enabled) and then to be re-booted 

from disk into the special auto-restart mode described 
below. 



If the system takes the automatic restart path, no halt occurs. 
Instead, the system first writes the contents of all of core onto the 
CRASH. SYS file and. then re-boots itself into core from the system 
disk. After the system has been re-booted into core, control jumps 
to the initialization routines. At this point the system recognizes 
the fact that it was not activated through a normal system start-up 
but rather through an automatic restart and consequently initializes 
itself in auto-restart mode. 

3.4.4 Auto-restart Mode Initialization 



When the system is initialized in auto-restart mode, control 
by-passes all parts of the initialization code which call for operator 
intervention (e.g. questions concerning the OPTION?, date, time, etc.) 
and initializes the system using information already stored in core. 
The system logs Job 1 in on KB0: under account [1,2] and causes it 
to run the System Library program INIT beginning at line 100. Since, 
in auto-restart mode, INIT begins at line 100 (rather than at its 
lowest line number) , it takes directions from the CRASH. CTL System 
Library file (rather than from the START. CTL file) . The CRASH. CTL 
file should direct INIT to perform all operations which the system 
manager considers necessary in the case of an automatic restart 
(e.g., to send an appropriate message to all terminals), and it should 
end with a BYE directive. If this is done before INIT exits to the 
system Monitor (as a result of its END statement) , it will force a 
character-string (See section 3.3.1) into KB0:'s input buffer (echoed 
on the terminal) which causes the system to log Job 1 off from KB0: 
and account [1,2]. At this point the system is in its normal time- 
sharing mode. 
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The print-out which appears on the console Teletype is similar in 
format to the following. Section 3.3.1 explains why most of these 
lines appear. (The I/O CHANNEL NOT OPEN line may or may not appear, 
depending on a random state of a word in core.) 

SYSTEM RELOADING ! ! ! 

V4A12 - SYSTEM PACK MOUNTED 
CHAIN "INIT" 100 
CATASTROPHIC ERROR 
PROGRAM LOST-SORRY 
I/O CHANNEL NOT OPEN 

READY 

SYSTEM INITIALIZATION PROGRAM 

nvc<t-ci/\ cirri * 
READY 

CONFIRM: SAVED ALL DISK PILES; 701 BLOCKS IN USE 
JOB 1 USER 1,2 LOGGED OFF KB0 AT 14-AUG-72 06: ^7 AM 
SYSTEM RSTS V4A-12 SYSTEM #213 
RUN TIME WAS .8 SECONDS 
ELAPSED TIME WAS 27 SECONDS 
GOOD MORNING 

As stated at the end of section 3.4.2, two error-traps within 
the same minute (be they catastrophic error or system crash) halt 
the system at address 54. 

See Appendix F for a flow-chart of the automatic restart 
logic. 
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CHAPTER 4 

SYSTEM ACCOUNTS, PRIVILEGE, AND SYSTEM FUNCTION CALLS 

i 
4.1 SYSTEM ACCOUNTS 

Any RSTS-11 system has three system accounts which are integral 
to the operation of the system. The MFD account [1,1] is used on 
the system device and other disk devices in the system to control 
access and file creation. It is described in Section 4.1.1. The 
system library account [1,2] is used by the RSTS-11 system to manage 
a library of generally available and restricted use system programs 
and message and control files. It is described in Section 4.1.2. 
The system account [0,1] contains RSTS-11 Monitor files and routines 
which are critical to the operation of the system. System account 
[0,1] is described in Section 4.1.3. 

4.1.1 MFD Account [1,1] on the System Device 

Access to the RSTS-11 system is controlled by the use of project- 
programmer numbers and passwords. The system manager, operating 
under his privileged account, creates a new account by the system 
program REACT. (See Chapter 5 for a description of REACT.) The 
project-programmer number and password of the new account are given, 
along with other information, to allow a user the means to access, 
system facilities. 

When a new account is created, the new account information is 
stored on the system device under the MFD account [1,1] . The 
password is stored in packed Radix-50 format. When the new user 
first creates a file, an area is created on the system device which 
is related directly to the user's account (project-programmer 
number) . This area is called the User File Directory or UFD. The 
UFD contains information concerning the files created under that 
account number. 

The account [1,1] contains a catalog of information of all User 
File Directories on the system, called the Master File Directory or 
MFD. When a user attempts to gain access to the RSTS-11 system by 
giving his account and password, the system program LOGIN is run 
automatically. LOGIN checks the MFD on the system device to determine 
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whether the account number and password given compare with one 
stored in the MFD. If so, the user is allowed access to the system. 

Other account information is stored in the MFD for each account 
in the system. This information is summarized in Table 4-1. 

The account information in the MFD is accessed by various system 
programs. The LOGIN system program has already been mentioned. The 
MONEY system program references the accumulated usage information. 
The system manager uses the MONEY system program to read and reset 
usage information. The disk storage information is referenced by 
the LOGOUT system program. The system manager can change the quota 
by use of the UTILTY system program. System access information is 
checked by the LOGIN system to determine the presence of a detached 
job. Refer to the descriptions of the individual system programs 
in Chapter 5 for more exact details. 

A facility is provided whereby the system manager can write 
programs which access the information in the MFD. See the descrip- 
tion of the system function SYS in Section 4.3. 

4.1.1.1 MFD on Other Devices - The system device exists in what is 
called the public structure. See Chapter 1-2 of the BASIC -PLUS 
Language Manual for a discussion of the public and private structures. 
Additional disk devices can be added to the public structure and to 
what is called the private structure. Each device that is added to 
the system also contains its own MFD. The MFD of each additional 
device is created when the system manager runs the stand-alone pro- 
gram DSKINT. See Chapter 6 for the description of DSKINT. The 
MFD of any device contains account and storage information for that 
device only. 

The MFD is treated differently on devices other than the system 
device. The RSTS-11 system allocates space for a user's file on 
the device in the public structure which has the most free space. 
If the user's account is not in the MFD of that device which has 
the most free space, his account information is added dynamically 
into the MFD of that device and a UFD is created for that user. 

The MFD on a device within the private structure is different. 

If a user desires to create a file on a disk within the private 
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Table 4-1 
Account Information Stored in the MFD on the System Device 



Type 


Description 


Explanation 


Identification 


Project-programmer 
number (account) 

Password 


Refer to Chapter 9 of BASIC- 
PLUS Language Manual. 

6 characters stored within 
2 words in Radix-50 format. 


Accumulated 
Usage 


Central Processor 
Unit (CPU) time 
(Run Time) 

Connect time 
(login time) 

Kilo-core-ticks 
(kct's) 

Device time 


Number of hours, minutes, 
and seconds to the tenth of 
a second (hh:mm:ss.t) of 
processor time the account 
has used to date. 

Number of hours and minutes 
(hh:mm) the user has been 
connected to the system 
via a terminal or remote 
line. 

Core usage factor. One kct 
is the usage of IK words of 
core for one tenth of a 
second . 

Number of hours and minutes 
of peripheral device time 
the account has used. 


Disk Storage 


Quota 


Number of 256-word blocks 
the user is allowed to 
retain at logout time. 


System 
Access 


Logins 
Logouts 


Number of times the user 
has logged in. 

Number of times the user 
has logged out. 
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structure, he cannot gain access if his account information does 
not already exist on the MFD of that device. The system manager 
or a privileged user grants WRITE access to a device in the private 
structure by entering the account information with the REACT system 
program which is described in Chapter 5. 

The MFD on devices within the public and private structure aside 
from the system device contains its own functional information. The 
information is pack label and account information. 

The pack label information consists of pack cluster size, pack 
status {private or public) , and pack identification (id) . The 
pack id is the 6 -character name in RADIX-50 format given at the time 
the disk was initialized via the stand-alone program DSKINT. The 
pack id is utilized whenever the disk is logically mounted via the 
system program UTILTY or via INIT. (A distinction must be made 
here between physical mounting and logical mounting. The disk is 
mounted physically by making the hardware ready to use the disk. 
The disk must be mounted logically by the system program UTILTY 
or from commands in START. CTL or CRASH. CTL by the INIT system pro- 
gram to enable the software to recognize and access the disk. The 
disk must also be logically dismounted before it is physically dis- 
mounted if corrupted disk structures are to be avoided.) 

The MFD contains accounting information much the same as that 
for each account in the MFD of the system device as described in 
Table 4.1. Also included are the device time and UFD cluster factor 
for the account. 

4.1.2 System Library Account [1,2] 

The system library account [1,2] is created on the system 
device during the REFRESH operation of the system build procedures. 
During subsequent operations of the system build procedures, the 
system manager creates the contents of the system library account 
[1,2]. This section describes the contents of account [1,2]. Refer 
to Chapter 2 of this guide for a description of how the system 
library is built. 

The system library catalogs, as files, system programs which 

are available to general users and to privileged users. It also 
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contains text and control files used by system programs. Refer to 
Chapter 2 of the RSTS-11 System User's Guide for a user-level 
description of system library files. 

The contents of the system library are presented in Table 4-2. 
For a more detailed description of the contents, refer to Chapter 4 
o f the RSTS-11 System User's Guide or Chapter 5 of this guide under 
the section explaining the related program. 

For operational purposes, the system library is accessed auto- 
matically during normal system start-up. As a result of specifying 
the START option when RSTS-11 is bootstrapped into core, the 
console keyboard is logged in automatically under account [1,2] . 

(See Section 3.3 of this guide for the description of the START 
option.) At this time, the commands in the file START. CTL, stored 
under account [1,2], are executed by the INIT system program, which 
is also stored under account [1,2]. Unless the system manager 
desires to add to or modify the contents of the system library 
after the system has been built, he need not log in under account 

[l',2]. 

For auto-restart purposes, the system library file CRASH. CTL is 
used by the INIT system program when recovering from system crashes. 
When auto-restart mode is entered, the RSTS-11 system performs 
actions similar to those described above for normal start-up, except 
that the contents of the system library file CRASH. CTL are executed. 
(See the description of auto-restart mode initialization in 
Section 3.4.4.) 

Two files, HELP. TXT and NOTICE.TXT, are provided to supply 
information to the user. The HELP. TXT file is printed automatically 
by the system program LOGIN if a user types HELP at a logged-out 
terminal. The NOTICE.TXT file is printed automatically by the 
system program LOGIN after a user has typed a valid account number 
and password during the log-in procedure. The NOTICE.TXT file 
provides a means by which the system manager can communicate 
up-to-date installation information to users. One other system 
library information file, PIP. TXT, is printed out when the user 
types HELP while running the related system program. 
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Table 4-2 
File Contents of System Library 



File Name 



Individual 
System 
Program 
Names 

HELP . TXT 



NOTICE . TXT 



ACCT.SYS 



START. CTL 



CRASH. CTL 



GRIPE.TXT 



DT13 mvp 



Status 



Both re- 
quired and 
optional 



optional 



optional 



required 
(if the 
STANDARD 
function 
of the 
program 
is used.) 

required 



required 



optional 



Origin 



T-i=ar\ loc 



accompa: 
the related 
system pro- 
gram 



Related 

Programs 



Compiled by manager from 
System Programs supplied 
with distribution kit. 



Created by manager 
via PIP during 
system generation 

Created by manager 
via PIP 



Created by manager 
at s vr stem Genera- 
tion time via PIP 



Created by manager 
via PIP 



Created by manager 
via PIP 



Dynamic creation 
and deletion on 
an as needed basis 



Created by trans- 
ferring the file 
from the RSTS-11 
kit to the system 
library using PIP 



LOGIN 



LOGIN 



REACT, 

r,PTPF 



INIT 



INIT 



GRIPE 



See Chapter 2 System 
Generation Procedures, 
"Building the System 
Library" 

System message file which 
contains general informa- 
tion about system use 

System message file which 
contains system informa- 
tion of daily interest; 
updateable by system 
manager . 

Standard account file used 
by REACT at system genera- 
tion time to facilitate 
automatic creation of user 
accounts and by GRIPE pro- 
gram to identify user making 
the comment. 

Normal system start-up 
control file for INIT. 
Refer to the description 
of INIT in Chapter 5 for 
the contents of this file . 

Auto-restart mode control 
file for INIT. Refer to 
the description of INIT 
in Chapter 5 for the 
contents of this file. 

Retains comments submitted 
by a user via GRIPE for 
inspection by the system 
manager. See Section 5.9 
for a description of GRIPE. 

System program file which 
contains operating instruc- 
tions of the related system 
program; printed in response 
to HELP while running the 
related system program. 
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The file GRIPE.TXT is created dynamically when a user runs the 
GRIPE system program. The system manager has read and delete 
access to the GRIPE.TXT file by means of the GRIPE system program. 

4.1. '3 System Account [0,1] on the System Device 

The system account [0,1] , like the system library account, is 
created on the system device during the REFRESH operation of the 
system build procedures. Account [0,1] has a password identical to 
the pack id and it contains name and retrieval information for 
system files. Account [0,1] is used solely by the RSTS-11 Monitor 
to execute various operational and control actions. In this respect, 
it is a direct access account for use by the RSTS-11 Monitor, and 
no user need be concerned with referencing its contents . The 
account can be used by a software specialist to make patches in the 
RSTS-11 system. This section describes the contents of the account 
in order to familiarize the system manager with the internal opera- 
tions of the RSTS-11 system. 

The contents of account [0,1] are presented in Table 4-3. 
The file SATT.SYS is the mechanism by which RSTS-11 controls the 
allocation and deallocation of disk storage space for the disk. The 
file maps the entire space on the disk in a bit map table called 
a SAT {Storage Allocation Table) . Each bit in a SAT represents 
an occupied disk cluster; each bit cleared in a SAT represents a. 
free disk cluster. Disk storage is typically allocated in multiples 
of the pack cluster size. A cluster represents a fixed number of 
256-word blocks, the number of 256-word blocks being determined by 
the cluster size. The blocks within a cluster are always contig- 
uous, whereas clusters may be scattered across the surface of the 
disk. 

Cluster sizes are defined for disk devices (packs) , directories, 
and files. Table 4-4 presents the types of clusters, the range of 
cluster sizes for each type, and the time when the sizes are 
defined. The pack cluster size determines how many contiguous 
256-word blocks are represented by each bit in a SAT on a disk, and 
also determines the minimum cluster size for directories and files 
on the disk. The directory cluster size determines the size to 
which a directory can expand, given the fact that a directory, 
whether an MFD or UFD, can occupy only seven clusters. The file 
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Table 4-3 
Contents of System Account [0,1] 



File Name 



SATT . SYS 



ERRM.SYS 



OVER. SYS 



BUFF. SYS 



SWAP . SYS 



CRASH. SYS 



CORE. SYS 



BADE. SYS 



Location 



Each disk device 
in system 



System or swapping 
disk only 



System or swapping 
disk only 



System or swapping 
disk only 



System or swapping 
disk only 

System disk only 



System disk only 



(not implemented 

each disk drive 
in the system) 



Status 



Required 



Optional 
(except on 
systems 
with a 
swapping 
disk) 

Optional 
(except on 
systems 
with a 
swapping 
disk) 

Required 
for 

DECtape 

Required 
Optional 



Reauired 



Description 



Storage allocation file 
containing retrieval 
and structure informa- 
tion for each disk 
device. 

Copy of error messages 
in CIL (CORE. SYS) which 
can be accessed and 
modified by system 
manager. 



Copy of non-resident 
(overlay) code in CIL 
(CORE .SYS) . 



File to retain DtCtape 
directories. 



File used to store user 
job images not in core. 

File used to store 
exact image of core 
following a system 

crash. 

RSTS-11 Core Image 
Library containing 
resident and non- 
resident (overlay) 
code, symbolic defini- 
tions, and error 
messages. 

File which catalogs 
bad blocks on disk. 
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Table 4-4 
Range of Cluster Factors 



Cluster 
Type 



Pack (for 
system disk) 

Pack (for 
non-system 
disk, public 
and private) 

Directory (both 
for MFD and UFD) 



File 



Minimum 
Size 



Pack cluster 
size 



Pack cluster 
size 



Maximum 
Size 



16 



16 



10 



10 



256 



10 



When 
Defined 



At REFRESH time (stored 
in MFD) 

At initialization time 
via DSKINT stand-alone 
program (stored in MFD) 



At creation of the direc- 
tory via either REFRESH, 
DSKINT, REACT, or SYS 
system function. 

At creation of the file 
via either an OPEN or 
OPEN FOR OUTPUT. 



cluster size is discussed extensively under the heading "CLUSTERSIZE 
Option" in Chapter 9 of the BASIC-PLUS Language Manual . 

The files SWAP. SYS, OVER. SYS, and BUFF. SYS are crucial to 
RSTS-11 system response time. These files should reside on a fast 
access disk. If the system disk is not a fast access type (i.e., 
not an RF type) , a copy of the non-resident (overlay) code is taken 
from the RSTS-11 CIL (CORE. SYS), placed in the file OVER. SYS and 
stored on the fast access disk, if available. The file SWAP. SYS 
keeps all jobs that are temporarily transferred out of core. 

DECtape processing is expedited by the use of BUFF. SYS. When 
a file on DECtape is opened, the directory of the DECtape is read 
into the file BUFF. SYS. Any updates to the DECtape directory which 
arise during processing cause the copy on the fast access disk to 
be manipulated. This technique eliminates the need for continuous 
winding and rewinding of DECtape. The copy of the DECtape 
directory in BUFF. SYS is read back to the DECtape when the last file 
open on the DECtape unit is closed or any output file is closed. 

The copy of the BASIC-PLUS error messages from the CIL (CORE. SYS) 

can be kept in the file ERRM.SYS, which can be accessed and modified. 
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The RSTS-11 Core Image Library is contained in the file 
CORE. SYS on the system disk. This file contains all executable 
code for system operations, resident and non-resident, and optionally 
contains code for stand-alone programs such as DSKINT and ROLLIN. 
The CRASH. SYS file can be created to retain a copy of core at the 
time of a system crash. (See Chapter 3 and Chapter 5 for discussion 
of system crashes and analysis of system crashes, respectively.) 

4.1.3.1 System Account [0,1] on Non-System Disks - The system 
account [0,1] on non-system disks contains pointers to system 
routines on the system disk, a BADB.SYS file, and a SATT.SYS file 
for recording the used space on the disk. The system account on 
non-system disks is created by the disk initializer program DSKINT. 
See Chapter 6 for a description of DSKINT. 

4.2 PRIVILEGE 

Certain accounts in the RSTS-11 system have special capabili- 
ties. These capabilities are outlined in this section. The 
accounts that have the special capabilities are called privileged 
accounts. An account is recognized as privileged by the RSTS-11 
system if its project number of the project-programmer number group 
is a 1. The system library account [1,2], discussed in a preceding 
section of this chapter, is an example of a privileged account. 

The system manager, operating under his own privileged 
account, designates accounts as privileged by assigning a project 
number 1 to the account when he creates it using the REACT system 
program. The available privileged account numbers are [1,3] 
through [1,254]. The assigned privileged accounts have the same 
special capabilities that the library privileged account [1,2] has. 
The user of an assigned privileged account also can create new 
accounts, as the system manager can. Privileged accounts, the 
system manager's as well as those he assigns, have the following 
special capabilities. 

1. Unlimited file access. See Section 4.2.1. 

2. Creation and modification of privileged compiled 
programs (with BAC filename extensions) . See 
Section 4.2.2. 

3. Use of privileged aspects of system programs. 
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4. Use of privileged SYS system functions and the 
PEEK function. See Section 4.3. 

The above listed capabilities are described in the remaining sections 
of this chapter and in Chapter 5. It must be emphasized that there 
is no fail safe and that no error messages are generated if the use 
of such special capabilities are to result in destruction, of the 
system. For this reason, it is suggested that the system manager 
assign privileged accounts sparingly. It is also recommended 
that the system manager create additional non-privileged accounts 
for himself and perform most of his functions under them. The 
system manager should use a privileged account only when necessary. 

4.2.1 Unlimited File Access 

No file in the RSTS-11 system can be protected against the user 
of a privileged account. A privileged user can create and delete 
files under any account number and can access files on LOCKED disks. 
Under such circumstances, no protection violation occurs. (Pro- 
tection violation is a normal user recoverable error, number 10, 
as described in Appendix C of the BASIC-PLUS Language Manual .) 

4.2.2 Creation and Modification of Privileged Programs 

A program is considered privileged when it has a BAC filename 
extension and a protection code of <128> or greater. For example, 
during the building of the system library in the system generation 
procedures, the system manager designates the required system 
programs SYSTAT and TTYSET privileged by assigning to their compiled 
forms a protection code of <128> or greater. To effect 
the assignment of privilege, the system manager uses' the NAME-AS 
statement. (Refer to Chapter 2 for the examples of designating 
SYSTAT and TTYSET privileged.) Any user of a privileged account 
can also designate a compiled program privileged. 

If a program is designated privileged, any user can run the 
program in privileged program status (provided he has READ access 
to the file) . The privileged program status exists for the duration 
of the program run. Privileged program status means that system 
operations, normally reserved to a user of a privileged account, 
are executed while running under a non-privileged account. 
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If the user running a privileged program interrupts execution 
of the program, such as by typing CTRL/C, the program loses its 
privileged status. 

The ability to designate a program as privileged allows the 
system manager to control use of privileged functions as the system 
programs do. For example, the program TTYSET allows a user to 
change characteristics of his terminal. Such an action is a 
privileged system function executable only by owners of privileged 
accounts. With the privileged program status, execution of the 
function by the owner of a non-privileged account does not cause 
the normal program trap . 

The same TTYSET program additionally allows a privileged user 
to change characteristics of a terminal other than his own. A 
check is built into the program to ensure that a user attempting 
to change the characteristics of a terminal other than his own is 
indeed a privileged user. As a result, the execution of privileged 
functions is made available to the non-privileged user but privileged 
features are restricted. The system manager likewise can control 
the use of privileged operations. 

A privileged user can modify privileged BAC programs. The user 
of a non-privileged account never has write access to a privileged 
BAC program. 

4.2.3 Use of Privileged Features of System Programs 

The owner of a privileged account can execute the privileged 
features of system programs. Since the list of privileged features 
is lengthy, an entire chapter is devoted to explaining them. Certain 
programs, such as TTYSET, SYSTAT, and MONEY, are privileged but 
contain features helpful to the general user. These programs are 
therefore described in the RSTS-11 System User's Guide for the 
non-privileged user. 

Two of the programs, TTYSET and MONEY, have privileged features 
about which the non-privileged user is not informed in the User's 
Guide. In Chapter 5 of this guide, only the privileged features of 
these programs are presented. The other program, SYSTAT, is dis- 
cussed in Chapter 5 of this guide in greater depth than is done in 
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the User's Guide although it contains no explicit privileged 
features. Thereby, the system manager can appreciate more fully 
the information returned by SYSTAT and be in a position to make 
sound judgments concerning the system. 

4.3 SYSTEM FUNCTION CALLS AND PEEK 

System function calls are separated into two classes, privileged 
and non-privileged. In the descriptions of each function call, the 
privileged ones are so labeled. The privileged system function calls 
can be used only by a privileged user, as defined in Section 4.2, 
or by a privileged program, as defined in Section 4.2.2. The non- 
privileged system function calls may be used by anyone and are 
completely safe in the sense that their use can do no damage to 
anyone other than the person who misuses them. In most cases, non- 
privileged system functions do no damage at all. 

4.3.1 System Function Formats and Codes 

The format of the call is: 

V$=SYS(CHR$(F)+0$) 

where : 



V$ is the target string variable (See individual descriptions) 

F is the SYS function code (See codes below) 

0$ is the optional (by function) parameter string passed 



CODE FUNCTION EXECUTED BY THE SYS CALL 

CANCEL +0 EFFECT ON CONSOLE TERMINAL 
No argument string is needed. 
Target string = passed string 

This function call cancels the effect of a CTRL/0 
typed at the terminal. In addition, it is used 
with the programmable CTRL/C trap, FIP code-7 . 
After a CTRL/C trap has occurred, teleprinter out- 
put is disabled until a SYS (CHR$ (0) ) is executed. 

1 ENTER TAPE MODE ON CONSOLE TERMINAL 
No argument string is needed. 
Target string = passed string 
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TiiXs LuncLion is identicaj. *_o v-ypmg uiiC xAir^j 
command on the terminal, as described in the 
RSTS-11 System User's Guide . 

ENABLE ECHOING ON CONSOLE TERMINAL 
(Also disable tape mode if present) 
No argument string is needed. 
Target string = passed string 

Cancels the effect of function codes 1 and 3. 

DISABLE ECHOING ON CONSOLE TERMINAL 
No argument string is needed. 
Target string = passed string 

Prevents information typed at the terminal from 
being echoed automatically by the Monitor. 
Information typed, such as a password, is kept 
secret but accepted by the system as valid input. 

ENABLE SINGLE CHARACTER INPUT MODE (ODT SUBMODE) 
No argument string is needed. 
Target string = passed string 

Allows a single character to be accepted as input 
from the terminal. Normally, the system waits 
until a line delimited by a RETURN, LINE FEED, 
or ESCAPE has been typed before accepting input. 
In single character mode, a character typed at 
the terminal is passed immediately to the pro- 
gram by the next keyboard input request state- 
ment without waiting for the delimiter. 

This function must be enabled prior to every input 
request statement that is to pass a single char- 
acter to the program. A GET statement is used as 
the input request statement. (INPUT or INPUT LINE 
statements cause repeated generation of the input 
request until a line terminator is detected and 
must not be used.) 

It is possible to use a SLEEP statement or a 
compute loop for a time delay between the SYS 
function call and the GET statement. Such a 
delay allows the operator time to type in more 
than one character before the system executes 
the GET statement. 

Since this function is used in the system program 
ODT.BAS, it is sometimes referred to as "ODT 
submode" . 

EXIT TO EDITOR WITH NO "READY" MESSAGE 
No argument string is needed. 
No string is passed back. 

Causes the same effect as the END statement, 
except that the READY message is not printed. 
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6 FIP function call (See Section 4.3.2.) 

7 GET CORE COMMON STRING 

No argument string is needed. 
Target string = core common string 

Allows a program to extract a single string from 
a data area loaded by another program running 
under the same job. The data area is called the 
core common and is from to 127 8-bit bytes long. 
Refer to SYS function code 8. 

8 PUT CORE COMMON STRING 

Argument string is string for core common. 
Target string = passed string 

Allows a program to load a single string in a 
common data area called core common. This string 
can be extracted later by another program, running 
under the same job and called via the CHAIN state- 
ment. The string is from to 127 8-bit bytes 
long. Refer to SYS function code 7. 

This function provides a means for passing a 
limited amount of information when a CHAIN state- 
ment is executed. If a larger amount of informa- 
tion is to be passed, it must be written to a disk 
file and read back by the later program. 

9 EXIT TO EDITOR AND SETUP "NONAME" PROGRAM 
No argument string is needed. 

No string is passed back. 

This function causes the same actions as the END 
statement placed in the code, and, in addition, 
clears the program out of memory. This is the 
proper method of stopping a program that is not 
to be rerun. Also, the same action is performed 
by the command NEW NONAME. 

4 • 3 . 2 SYS System Function Calls to FIP (Function Code 6 ) 

The SYS system function call whose code is 6 is a more special- 
ized case of the general system function call. It is specialized by 
an additional code, called the FIP code. The FIP code causes a call 
to be made to special non-resident code that performs File Proc- 
essing. 

The format of the call is: 

V$=SYS(CHR$ (6%)+CHR$(F0)+O$) 
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where : 



V$ is the target string variable (See below.) 

FO is FIP function (See codes below.) 

0$ is the optional (by function) parameter string, 



The general format of the target variable (V$) is: 



BYTE 1 JOB NUMBER TIMES 2 

BYTE 2 VALUE OF INTERNAL FUNCTION CALLED 

(MEANINGLESS TO GENERAL USER) 
BYTES 3-30 BYTES COPIED FROM BYTES 4-37 (OCTAL) 

OF FIRQB (SEE INDIVIDUAL DESCRIPTIONS) 



NOTE 
30 bytes are always passed back. 

The proper use of the FIP system function call requires that 
the user program build a parameter string to pass and that the pro- 
gram later extract the data from the returned string, called the 
target string. Each call returns a string of 30 bytes, each byte 
(or character) of which may or may not contain useful information. 
The descriptions of the FIP codes specify the contents of each byte 
in the string, from which the user determines whether the information 
contained is of interest. 

A recommended method of building a 30-byte string to pass is 
to dimension a 30-byte list and set the items in the list to values 
which map into those required in the optional parameter string for- 
mat. The list can later be set to a character string by the CHANGE 
statement before it is passed as the parameter string of the FIP 
system function call. The resulting character string is in proper 
format and contains the correct byte values so that it may be 
placed as the optional parameter string of the FIP system function 

flail P^-i- ay am-rjl a • 

10 DIM A%(30) Ithe string is 30 bytes long 

20 A%(0)=30 10th element is length of list 

30 A%(1)=6 ISYs'call code 6 (FIP call) 

40 A%(2)=6 1FIP code 6 (attach) 

50 A%(3)=10 Uob number times 2 of job to 

'.attach to (Job 5) 
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The remainder of the bytes are supplied according to the require- 
ments of FIP call code 6 and the user's requirements. 

Following the code which builds the list is the CHANGE statement 
and the call itself, as shown below. 



CHANGE k% TO A$ 



B$ = SYS(A$) 



! generates character 

! string from the integer 

!list 

! invoke system function 

■call 



In the case of the FIP call using FIP code 6, the action performed 
(attach) is of importance and the string returned does not contain 
information that is worthwhile to the user. 

Other FIP system function calls return a target string which is 
of prime interest to the user program. In such a case, the user pro- 
gram transforms the returned byte string to the list of integer items. 
For example, the statement 

CHANGE SYS(A$) TO A% 

performs the conversion so that the data of the individual items can 
be extracted and converted to meaningful form. 

In the instance of a FIP code of 15, as an example, bytes 11 
and 12 of the returned string are the file name extension encoded in 
Radix-50 format. The integer representation of each byte, however, 
occupies a full word, 16 bits in length. Thus, list items number 
11 and 12 would appear as the following: 



A%(11) 



A%(12) 



15 




7 










Byte 11 




15 




7 










Byte 12 





Byte 11 contains the low byte portion of the Radix-50 word; byte 12 
contains the high byte portion of the Radix-50 word. The two bytes 
must be combined into a single word and converted to the proper 
character string representation. This is accomplished by the 
following : 
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S$ = RAD$(AJt(ll) + SWAP5S(A56(12))) 

The SWAP% function reverses the bytes (the low byte takes the high 
byte position and vice-versa) in an integer word. Graphically, the 
operation appears as follows: 



15 


7 








15 1 










Byte 12 


— »- 


SWAPS (A% (12)) 


►- 


Byte 12 






Thus, byte 12 takes the high byte position in the word. The two 
words are then combined by the + operator- to form one word. The 
RAD$ function performs the conversion on that one integer word to 
produce the 3-character string representation of the file name 
extension. The character string is assigned to the character variable 
S$. S$ is converted to a usable format. 

The remainder of the section describes the individual FIP system 
function calls and the structures of the parameter string options and 
of the returned target string. 

DESCRIPTIONS BY FUNCTION CODE (F0) 



■15 



ERROR LOGGING 

Reserved for DIGITAL use. 



-14 



SYSTEM DATE AND TIME CHANGER 
0$=CHR$(HDA)+CHR$(LDA)+CHR$(HTI)+CHR$(LTI) 



where : 

L means Low byte and H means High byte 
DA means system date 
TI means time of day 

No useful data is returned. 



This function changes the monitor date and time of day 
values which are returned by the DATE$(0#) and TIME$(0$) 
functions in BASIC-PLUS. 
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-13 PRIORITY AND QUANTUM FACTOR CHANGER 

0$=CHR$ ( J% ) +CHR$ ( ?% ) +CHR$ ( QM)+CHR$ (QA) 

where : 

J% Is the job number. means the current job. 

V% is the priority value between -128 (lowest) and +127 
(highest) 

QM is the quantum multiplier factor. 

QA is the quantum adder factor. 

No useful data is returned. 



The user program can supply values to alter the job's 
chance of running and to Increase or decrease the amount 
of time the system allows the job to run. The system 
automatically sets a job's priority to -1. (During the 
LOGIN procedure, a job's priority is temporarily 0.) 
The system allows a job to run for N number of clock 
interrupts (the time quantum) according to the following 
algorithm. 

N = ((J) * 2 QM ) + QA 



where : 



J = job size In K words. 

QM = quantum multiplier factor which can be between 
and 127. If QM=0, then N=QA. 

QA = quantum adder factor which must be between 
and 127. 

The system automatically sets QM to 1 and QA to 4 for all 
jobs. 



•12 Not used. 



•11 BACKUP FILE STAT CHANGER (PRIVILEGED) 

0$=CHR$ ( N ) +CHR$ ( LDLA ) +CHR$ ( HDLA ) +CHR$ ( LDC ) +CHR$ ( HDC ) + 
CHR$(LTC)+CHR$(HTC) 

N=CHANNEL NUMBER (1 TO 12) 

L PREFIX IS LOW BYTE: H PREFIX IS HIGH BYTE 

DLA=DATE OF LAST ACCESS 

DC=DATE OF CREATION 

TC=TIME OF CREATION 



No useful data is returned. 
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This function changes the date of last access, date of 
creation, and time of creation fields for a disk file. 
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FILE NAME STRING SCAN 

0$=STRING TO SCAN 

Loaded FIRQB is passed back as follows: 



JOB NUMBER TIMES 2 

9 



BYTE 


1 


BYTES 


2-4 


BYTE 


5 


BYTE 


6 


BYTES 


7-10 


BYTES 


11-12 


BYTES 


13-20 


BYTE 


21 


BYTE 


22 


BYTES 


23-24 


BYTE 


25 


BYTE 


26 


BYTES 


27-30 



PROG NUMBER OR 

PROJ NUMBER OR 

FILE NAME OR (RADIX-50 FORMAT) 

EXTENSION OR (RADIX-50 FORMAT) 



IF NO PROTECTION; ELSE 255 

PROTECTION IF SPECIFIED 

DEVICE NAME OR 

DEVICE NUMBER IF SPECIFIED 

IF NO NUMBER; ELSE NON-0 
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This function causes the string passed to be scanned 
and converted into the form necessary for further FIP 
system function calls. 

-9 HANGUP A DATASET (PRIVILEGED) 
0$=CHR$(N)+CHR$(?) 

N=KEYBOARD NUMBER OF LINE TO HANGUP (MUST BE DC11 LINE) 
?=Anything such that an even number of bytes is passed. 
No useful data is returned. 

-8 GET OPEN CHANNEL STATISTICS 
0$=CHR$(N) 

N=CHANNEL NUMBER (0 TO 15) 
Data returned : 

BYTES 3-4 WORD 1 OF FCB/DDB 
BYTES 5-6 WORD 2 OF FCB/DDB 

BYTES 23-24 WORD 11 OF FCB/DDB 

BYTES 25-26 WORD 12 OF ECB/DDB 

BYTES 27-28 WORD 16 OF FCB/DDB 

BYTES 2 9-30 WORD 15 OF FCB/DDB 

-•7 CONTROL/C TRAP ENABLE 

No parameters are needed. 

Nothing worthwhile is passed back. 

After this FIP function is executed in a user program, 
the Run Time System treats the first CTRL/C subsequently 
typed on any terminal belonging to the job as a trap- 
pable error (ERR=28) . Upon execution of the trap, the 
terminal is placed in CTRL/O mode (all output to the 
terminal is suppressed), and control is immediately 
passed to the numbered program statement which has 
been designated as the error-handling routine by the 
last execution of an ON ERROR GOTO statement. After 
the trap, the user program must issue a SYS call 
(code 0) to re-enable programmed output at the terminal. 

Such trapping of CTRL/C, however, guarantees only that 
a defined set of statements are executed when CTRL/C 
is typed. It is not possible to resume execution at 
the exact point where the CTRL/C occurred. 

If certain critical sections of BASIC-PLUS code are to 
be completely immune to possible CTRL/C aborts, 
three actions must occur. 

(a) The job must detach itself from its terminal. 
See the description of FIP code +7. 

(b) The program must have CLOSEd all channels on 
which other terminals in the job had been 
OPENed . 

(c) The job must have DEASSIGNed any terminal 
which had been previously ASSlGNed to it. 
See the description of FIP code +11. 
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If the three actions occur, program execution under the 
job proceeds immune to any CTRL/C. 

After the job has completed its critical processing 
in the detached state, one of two actions can occur. 

(a) The job can kill itself by means of FIP code +8, 

(b) The job can find a free terminal (presumably 
the one from which it detached itself) , and 
"force" into that terminal input buffer the 
character strings needed for logging into the 
system and attaching the job to the terminal. 
(See the descriptions of FIP codes -4, +4, 
and +6.) 

POKE CORE (PRIVILEGED) 

0$=CHR$ (LA) +CHR$ (HA) +CHR$ (DATA) + . . . 

LA=low byte of address 

HA=high byte of address 

Data is the data byte stream. 

No useful data is returned. 
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This FIP function changes the contents of memory and 
can destroy the system very easily. It is the most 
dangerous function and must be used with care. 

BROADCAST TO TERMINAL (PRIVILEGED) 

0$=CHR$ (N) +M$ 

N=Keyboard number to receive output message 

M$=Message to broadcast (must not be null string) 

No useful data is returned. 
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FORCE INPUT TO TERMINAL (PRIVILEGED) 

0$=CHR$(N)+I$ 

N=Keyboard number to receive forced input 

I$=String to force to terminal (must not be null string) 

No useful data is returned. 
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GET MONITOR TABLE LOCATIONS 
No parameters are needed . 
Data returned: 



BYTE 


4 


MAXIMUM JOB NUMBER ON SYSTEM 


BYTES 


5-6 


"DEVCNT" 


BYTES 


7-8 


"DEVPTR" 


BYTES 


9-10 


"CORTBL" 


BYTES 


11-12 


"JOBTBL" 


BYTES 


13-14 


"JBSTAT" 


BYTES 


15-16 


"JBWAIT" 


BYTES 


17-18 


"UNTCLU" 


BYTES 


19-20 


"UNTCNT" 


BYTES 


21-22 


"SATCNT" 


BYTES 


23-24 


"NAME1" 


BYTES 


25-26 


"NAME 2" 


BYTES 


27-28 


TODAY'S DATE IN INTERNAL FORM 
NOTE 



The following (decimal) locations are 
fixed in the resident monitor area in 
core for version 4 A. They nay be 
examined with the PEEK function. 
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IDATE 


36 


ITIME 


38 


DATE 


2048 


TIME 


2050 


JOB 


2056 (BYTE) 


JOBDA 


2098 


FREES 


2108 




2110 


FREEB 


2112 




2114 


DEVNAM 


2206 



-2 DISABLE FURTHER LOGINS (PRIVILEGED) 
No parameters are needed. 
No useful data is returned. 

-1 ENABLE FURTHER LOGINS (PRIVILEGED) 
No parameters are needed. 
No useful -data is returned. 

NOTE 

Function codes on up require filling 
called for bytes with 0's if parameter 
string (0$) is too short. 



CREATE 

Data pa 

BYTE 

BYTE 

BYTES 

BYTES 

BYTES 

BYTE 

BYTE 



USER ACCOUNT 
ssed: 



(PRIVILEGED) 



7 

8 

9-12 

13-14 

23-24 

25 

26 



PROGRAMMER NUMBER {0 TO 255) 
PROJECT NUMBER (1 TO 255) 
PASSWORD IN RADIX-50 (ONLY IF 
DISK QUOTA IN 256 WORD BLOCKS 
DISK TYPE (DF,DK,DP - MEANS 
DISK UNIT (0 TO N) — 



255 



SYSTEM ENTRY) 
( MEANS NO QUOTA) 
SYSTEM) 
IF BYTES 23-24 ARE 
THEN THIS IS 
THIS BYTE IS 255 IF (AND 
ONLY IF) BYTE 25 CONTAINS 
A REAL UNIT DESIGNATION. 
IN THIS WAY WE DISTIN- 
GUISH BETWEEN 'DK:' AND 
'DK0: ' . 



BYTES 27-28 UFD CLUSTER SIZE (1 TO 16 - DEFAULTS) 
No useful data is returned. 



DELETE USER ACCOUNT (PRIVILEGED) 

Data passed: 

BYTE 7 PROGRAMMER NUMBER — YOU CANNOT DELETE 

BYTE 8 PROJECT NUMBER — [1 ,1] , [1 , 2] , [ ,1] 

BYTES 23-24 DISK TYPE (DF,DK,DP - MEANS SYSTEM) 

No useful data is returned. 



CLEANUP A DISK PACK (PRIVILEGED) 
Data passed: 

BYTES 23-24 DISK TYPE (DF,DK,DP 
BYTE 25 DISK UNIT (0 TON) 



IS SYSTEM) 

IF BYTES 23-24 ARE 

THEN THIS IS 
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BYTE 



26 



255 



No useful data is returned. 



THIS BYTE IS 255 IF (AND ONLY 
IF) BYTE 25 CONTAINS A REAL 
UNIT DESIGNATION. IN THIS WAY 
WE DISTINGUISH BETWEEN 'DK: 1 
AND ' DKO : ' . 



DISK PACKS AND TERMINAL STATUS (PRIVILEGED) 
Data passed: 



BYTE 



ODD = 



2 

4 

6 



TERMINAL STATUS 
MOUNT DISK PACK 
DISMOUNT DISK PACK 
LOCK OUT DISK PACK 
UNLOCK DISK PACK 



For termi 


BYTE 


4 


BYTE 


5 


BYTE 


6 


BYTE 


7 


BYTE 


8 


BYTE 


9 


BYTE 


10 


BYTE 


11 


BYTE 


12 


BYTE 


13 


BYTE 


14 


No use 


ful 



nal status (0 means no change) : 

255=::YOUR TERMINAL ; N=::KBN 
NEW FORM WIDTH (1 TO 255) 
128=::TAB ; 255=: :NO TAB 
128=: :NO FORM ; 255=::FORM 
128=: :LC ; 255=: :NO LC 
128=: :NO XON ; 255=::XON 
128=::ECHO ; 255=: :NO ECHO 
128=: :NO SCOPE ; 255=::SCOPE 
128=::NO 175,176 ; 255= : :175 , 176 
255=::SERIAL LA30 FILL 
1 TO 7=::0 TO 6 FILL FACTOR 
1 TO 4 FOR DC 11 SPEEDS TO 3 
data is returned. 



For MOUNT, DISMOUNT, LOCK, UNLOCK: 
BYTES 23-24 DISK TYPE (DF,DK,DP) 
BYTE 25 DISK UNIT (0 TO N) 
BYTE 26 255 



For MOUNT: 
BYTES 7-10 



PACK ID IN RADIX 5 



No useful data is returned. 



LOGIN (PRIVILEGED) 



Data passed: 


BYTE 


7 


BYTE 


8 


BYTES 


9-12 


UCLL.CL J. C LUX 11CU - 


BYTE 


3 


BYTES 


4-N 



PROGRAMMER NUMBER — NEVER CAN 
PROJECT NUMBER — BE [0,1] 
PASSWORD IN RADIX 50 

NUMBER OF JOBS THIS ACCOUNT (>=1) 

JOB NUMBERS (*2) OF DETACHED JOBS (0 IS END) 



LOGOUT (PRIVILEGED) 

No argument string is needed. 

No useful data is returned. 

ATTACH (PRIVILEGED) 

Data passed: 

BYTE 3 JOB NUMBER TIMES 2 TO ATTACH TO 

BYTES 7-8 PPN OF JOB TO ATTACH TO 

BYTES 9-12 PASSWORD OF PPN IN RADIX 5 

No useful data is returned. 
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DETACH (PRIVILEGED) 

No argument string is needed. 

No useful data is returned. 

CHANGE PASSWORD/QUOTA OR KILL JOB (PRIVILEGED) 

Data passed for change : 

BYTES 7-8 PPN OF ACCOUNT TO CHANGE (0 MEANS YOU) 

BYTES 9-12 NEW PASSWORD IN RADIX 50 (0 MEANS SAME) 

BYTES 13-14 NEW DISK QUOTA IN BLOCKS 

BYTE 21 255 IF QUOTA IS REAL 

BYTE 28 

Data passed for KILL: 
BYTE 3 JOB NUMBER 
BYTE 28 255 
No useful data is returned. 
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ERROR MESSAGES 

Data passed: 

BYTE 3 ERROR NUMBER (0 TO 127) 

Data returned: 

BYTE 2 KEYBOARD NUMBER TIMES 2 ** EXCEPTION ** 

BYTES 3-30 MESSAGE ENDING WITH A NULL £0) BYTE 

ASSIGN A DEVICE 

Data passed: 

BYTES 23-24 DEVICE NAME (DT,PR,PP ,MT,CR,LP ,KB) 

BYTE 25 DEVICE UNIT (0 TO N) — BYTE 25 IS USED IF 

BYTE 26 — BYTE 26 IS 255 

No useful data is returned. 



11 



12 



13 



14 



DEASSIGN A DEVICE 

See ASSIGN A DEVICE above. 

DEASSIGN ALL DEVICES 

No argument string is needed, 

No useful data is returned. 

ZERO A DEVICE 



Data passed: 


BYTES 


5,6 


BYTES 


23-24 


BYTES 


25 



BYTE 



26 



No useful data is returned. 
READ/RESET ACCOUNTING DATA 



PPN IF PRIVILEGED (0 IS YOUR'S) 

DEVICE NAME (DT,DF,DK,DP - MEANS SYSTEM) 

DEVICE UNIT (0 TO N) — IF BYTES 23-24 ARE 

THEN THIS IS 
255 — THIS BYTE IS 255 IF 

(AND ONLY IF) BYTE 25 
CONTAINS A REAL UNIT 
DESIGNATION. IN THIS 
WAY WE DISTINGUISH 
BETWEEN ' DK : ' AND 
'DK0: ' . 



Data passed: 


BYTES 


3-4 


BYTES 


5-6 


BYTES 


7-8 


BYTES 


23-24 


BYTE 


25 



INDEX (1 TO N) OR FOR LOOKUP ON PPN 
FOR READ ONLY/NON-0 FOR READ AND RESET 
PPN IF LOOKUP ELSE ANYTHING 
DISK TYPE (DF,DK,DP - MEANS SYSTEM) 
DISK UNIT (0 TO N) - IF BYTES 23-24 ARE 

THEN THIS IS 
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BYTE 26 



Data returned 
BYTES 5-6 



>55 



— THIS BYTE IS 255 IF (AND ONLY 
IF) BYTE 25 CONTAINS A REAL 
UNIT DESIGNATION. IN THIS WAY 
WE DISTINGUISH BETWEEN 'DK:' 
and 'DK0: 



DISK OWNED BY ACCOUNT 

PPN OF ACCOUNT 

PASSWORD IN RADIX 50 OF ACCOUNT 

CPU TIME (TENTHS OF SECONDS) 

CONNECT TIME (MINUTES) 

KILO-CORE-TICKS (1K'S*TENTHS OF SECONDS) 

DEVICE TIME (MINUTES) 

NUMBER OF LOGINS 

NUMBER OF LOGOUTS 

DISK QUOTA IN BLOCKS (0 MEANS NO QUOTA) 

UFD CLUSTER SIZE 
If not privileged then forces: 
BYTES 3-4 TO (DO LOOKUP) 
BYTES 5-6 TO (READ ONLY) 
BYTES 7-8 TO CURRENT PPN FOR LOOKUP 



BYTES 


7-8 


BYTES 


9-12 


BYTES 


13-14 


BYTES 


15-16 


BYTES 


17-18 


BYTES 


19-20 


BYTE 


21 


BYTE 


22 


BYTES 


27-28 


BYTES 


29-30 



15 



DIRECTORY INFORMATION 

Data passed: 

BYTES 3-4 INDEX (0 TO N) 

BYTES 5-6 PPN (0 MEANS CURRENT PPN) 

BYTES 23-24 DEVICE TYPE (DT,DF,DK,DP 

BYTE 25 DEVICE UNIT (0 TO N) — 

BYTE 26 255 



- MEANS SYSTEM) 
IF BYTES 23-24 ARE 
THEN THIS IS 
THIS BYTE IS 255 IF 

(AND ONLY IF) BYTE 25 
CONTAINS A REAL UNIT 
DESIGNATION. IN THIS 
WAY WE DISTINGUISH 
BETWEEN ' DK : ' AND 

'DK0: ' . 



Data returned : 
BYTES 7-10 



BYTES 
BYTES 
BYTE 
BYTES 



11-12 
13-14 
15 
17-18 



BYTES 19-20 

BYTES 21-22 

BYTES 27-28 

BYTES 29 



FILE NAME IN RADIX 50 

EXTENSION IN RADIX 50 

LENGTH IN BLOCKS/SECTORS 

PROTECTION 

DISK - DATE OF LAST ACCESS 

TAPE - DATE OF CREATION 

DISK - DATE OF CREATION 

DISK - TIME OF CREATION 

DISK - FILE CLUSTER SIZE 

NUMBER OF ENTRIES (DISK=8; TAPE=6) 



4.3.3 The PEEK Function 

There is one final privileged function in RSTS-11. This is the 
PEEK function, which permits the user to examine words in the PDP-11 's 
core memory. It is called as follows: 

I%=PEEK(J%) 
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PEEK takes an integer argument and returns an integer value, 
which is simply the contents of the core location specified by the 
integer argument. Since on the PDP-11 words are addressed always as 
even numbers (odd addresses are byte addresses, not word addresses), 
the user must be careful to always specify an even integer argument 
to PEEK. 

PEEK is privileged since any attempt to access an odd address 
(i.e., failing to use an even integer argument) or attempting to 
access nonexistent memory will cause a catastrophic error. 

The PEEK function is normally used in conjunction with the 
system function call that returns various monitor table locations. 
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CHAPTER 5 
PRIVILEGED FEATURES OF SYSTEM PROGRAMS 



A system program is coded in BASIC-PLUS, and stored either as a 
disk-resident system library file in compiled form under account [1,2] 
or as a file in source form in the RSTS-11 kit. System library files 
are described in Section 2.4.4 of the RSTS-11 System User's Guide, 
and the system library account [1,2] is described in Section 4.1.2 
of this guide. The system manager determines the contents of the 
system library during the system generation procedures by including in 
or omitting from the installation's system library account those 
system programs supplied by DIGITAL. 

This chapter covers those features of the system programs which 
the system manager or privileged user needs to be aware of to operate 
and manage the RSTS-11 system. The description of the system programs 
given in Chapter 4 of the RSTS-11 System User's Guide is presented in 
a modular format such that the system manager, as he deems necessary, 
can remove a description of a system program from that guide without 
affecting the descriptions of other system programs. As a result, the 
system manager can determine what the user at the local installation 
needs to know about the individual system programs provided on the 
RSTS-11 system. 

Other system programs are documented in formatted ASCII files with 
DOC filename extensions in the RSTS-11 kit. These so called docu- 
mentation files can be transferred from the RSTS-11 kit to a keyboard 
or line printer by using the PIP system program and its /FA switch. 
See Chapter 4 of the RSTS-11 System User's Guide for a description 
of PIP. 

Many of the system programs make use of SYS system function calls. 
Therefore, a firm understanding of the techniques and strategy in the 

use of system programs leads to an easier understanding of the opera- 
tion of certain SYS system function calls. 
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References are made in the discussion of SYS system function 
calls to programs described in this chapter as an aid in grasping the 
concept of coding SYS calls. 

The format of the program descriptions in this chapter is mainly 
expository. Reference aids have been included in appending the rele- 
vant system program filename to the section heading and by inclusively 
tabulating all relevant program commands or options. The description 
of each program informs the system manager how the related system pro- 
gram must be~ stored and with what protection code. 

5.1 CONTROLLING SYSTEM START UP - INIT 

The user can control system start up by means of the system 
initialization program INIT. System start up occurs when the user 
executes the START option or when the monitor attempts an automatic 
restart after a system crash. At start up time, the monitor auto- 
matically runs INIT which, in turn, executes special commands on the 
system. By the ability to specify these special commands, the user 
controls the actions which occur at system start up. 

To control system start up efficiently, the system manager 
must understand the conditions in effect at start up time. The follow- 
ing conditions pertain. 

a) Login attempts are prohibited (the monitor disables the 
login capability) . 

b) The monitor logically mounts only the system disk. 

c) No output is made to any terminal. 

d) The monitor logs the console terminal (KBjJ:) onto the 
system under the system library account [1,2]. 

e) At the console terminal, the monitor executes the command 
equivalent to CHAIN "INIT" or CHAIN "INIT" 100. 

As a consequence of condition (e) , INIT runs and reads one of two 
control files on the system disk (SY0:) under account [1,2]: either 
START. CTL or CRASH. CTL. The two control files contain special commands 
for the initialization of the system for time sharing. The following 
sections describe the INIT commands and their usage. 
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5.1.1 INIT Program Commands 

The RSTS system is not fully initialized until INIT runs and 
executes commands in the control file. By specifying the INIT commands 
described in Table 5-1, the system manager can control system start up 
according to requirements at the local installation. For example, 
the system possibly uses other disk devices in addition to the system 
disk. By means of the MOUNT command, the system manager can make 
such devices in the public and in the private structure immediately 
available to users before they can log into the system. The local 
start up procedures must include making the specified devices physically 
ready on the proper drive units. 

To execute other actions on the system, the system manager can 
cause INIT to execute BASIC-PLUS commands and programs. Executing 
the LOGINS command enables further logins on the system. The LOGIN 
command automatically logs a specified job onto the system at a 
designated terminal to allow execution of commands and programs. For 
example, the FORCE command can run the TTYSET system program at the 
terminal and can subsequently execute commands to establish terminal 
characteristics of certain keyboards. The SEND command prints text 
on all on-line terminals. 

The following sample START. CTL file and accompanying explanation 
shows the usage of INIT commands. 



MOUNT 


DK1: 


PACK1 




(line a) 


MOUNT 


DK2: 


PRIV1 




(line b) 


LOGINS 








(line c) 


LOGIN 


KB1: 


[1,5] 




(line d) 


FORCE 


KB1: 


RUN $TTYSET 


(line e) 


FORCE 


KB1: 


KB1: 




(line f) 


FORCE 


KB1: 


VT05 




(line g) 


FORCE 


KB1: 


EXIT 




(line h) 


FORCE 


KB1: 


BYE F 




(line i) 


FORCE 


KB0: 


RUN $ERRCPY 


(line j ) 


SEND 
END 


RSTS 


IS NOW 


ON THE AIR . . 


(line k) 
(line 1) 



5-3 February 1975 



Command Name 
and Format l 



LOGINS 



SENDl_|XXX 



LOGIN|_jKBn : i_i [n ,m] 



FORCELJKBn : LJxxx 



MOUNTi_idev:id 



BYE or END 



Table 5-1 
Control File Contents 



Use 



Allows users at both local and remote 
terminals to type requests to the LOGIN 
system program. 



Transmits the optional text xxx to all 
keyboards currently online except the 
console keyboard ( KB0:) ■ 



Logs the terminal specified by KBn: onto 
the system using the account indicated by 
[n,m]. INIT automatically looks up the 
password . 

NOTE 

Cannot be used on KB0: because INIT must 
run on that terminal. _____ 



Causes the text xxx to be placed in the 
input buffer of the terminal specified by 
KBn: and executed as if typed at that 
terminal. The text can be any BASIC-PLUS 
command or TTYSET system program SET 
commands. The LOGINS command must appear 
before the FORCE commands can be executed. 

NOTE 

If the + character is the first character 
of the text xxx, a CTRL/C is placed in 
the terminal buffer ahead of the specified 
text xxx. However, INIT generates an 
error if an attempt is made to force a 
-t-C to KB0. 



Causes the disk unit specified by the de- 
vice designator dev: and by the pack identi- 
fication (id) to be logically recognized 
by the RSTS system. Additionally, the 
MOUNT command as used in the control file 
causes a clean operation (if necessary) 
and an unlock operation. Refer to Section 
5.3.2 for information concerning mount, 
clean and unlock operations. 



Causes execution of the INIT system program 
to be terminated, BYE causes the job run- 
ning under account [1,2] to be logged out, 
thus freeing the console keyboard for other 
use and preventing unauthorized use of 
account [1,2]. END must be used in place of 
BYE when running ERRCPY since END does not 
logout the job running ERRCPY under account 
[1,2]. See Section 5.10 for a description 
of ERRCPY. 



] The notation i_J indicates that a space character is required. 
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The user makes other disks available on the system as shown at lines 
a and b. Line a causes the system to recognize the additional disk 
cartridge PACK1 of the public structure on RKll drive unit 1. The 
user must mount all public disks (except the system disk) in this 
manner if all' user files are to be available immediately. The system 
also cleans (if necessary) and unlocks PACKl so that users can create 
files on it. 

Line b causes the same results as line a but for the disk cartridge 
PRIV1 in the private structure. 

Logins must be enabled before attempting to log a terminal onto 
the system. The LOGINS command at line c is required to enable logins 
and to allow users access to the system. 

The command at line d logs in a job at keyboard number 1 under 
account [1,5]. INIT automatically looks up the password of the account. 
In this manner, secrecy is maintained by not requiring passwords in 
control files. 

The commands at lines e through h run the TTYSET system program 
to set terminal characteristics. For more information on TTYSET, see 
Section 5.7. 

At line i, keyboard number 1 is logged off the system to prevent 
unauthorized use of the account. 

The command at line j causes the console terminal (KBJZf:) to run 
the ERRCPY system program under account [1,2]. This action enables. the 
RSTS system to take advantage of hardware error logging on the system. 

The SEND command notifies users that time sharing operations 
have begun. The message is. printed on all terminals on line to RSTS. 

The END command at line 1 terminates the INIT program running 
at the console terminal. However, the command leaves KB0: logged into 
the system so that the system can execute the command forced into the 
keyboard buffer by the command at line j. Since ERRCPY detaches from 
the terminal, KB0: does not remain logged into the system after 
initialization. 
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5.1.2 Creation and Usage of Control Files 

The INIT system program control files START. CTL and CRASH. CTL 
must contain commands to properly initialize the RSTS system and must 
be stored on the system disk (unit of the public structure) . 
The files included in the RSTS system generation kit are only samples 
and, without modification, may not execute properly on a given 
system. The system manager must ensure that the files include the 
necessary commands to initialize the local installation. For example, 
to replace the sample START. CTL file supplied with the RSTS kit, run 
PIP and proceed as follows. 

RUN $PIP 

PIP RSTS V04B-17 SYSTEM #880 
JSY0 : START . CTL$<KB : /FA 

(user types his new INIT commands.) 

h 

I 

The procedure shown ensures that the new file is created on unit 
(SYJ3:). This is important since, when INIT runs, only the system disk 
in the public structure is mounted. 

It is important that both control files perform the following 
functions : 

a) Mount all non-system public disks, 

b) enable logins, 

c^ set keyboard characteristics for non—ASR33 terminals- and 

d) run any system programs which must execute during time 
sharing. 

Since, at start up time, the system sets the characteristics 
of all terminals to those of an ASR33-type terminal, the user must 
run the TTYSET system program to determine the correct characteristics, 
For example, if keyboards 1 and 3 are LA30S-type terminals to run at 
300 baud, if keyboard 2 is an ASR33-type terminal, and if keyboard 4 
is a VT05 to run at 300 baud; the system manager can specify the 
following sequence of commands to properly set the characteristics. 
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LOGIN 


KB4: 


[1,5] 


FORCE 


KB4: 


RUN STTYSET 


FORCE 


KB4: 


KB4: 


FORCE 


KB4: 


VT05 


FORCE 


KB4: 


KB1: 


FORCE 


KBit: 


LA30S 


FORCE 


KB4: 


KB3 


FORCE 


KB4: 


LA30S 


FORCE 


KB4: 


EXIT 



The sequence of INIT commands shows the optimum use of a keyboard 
on which to execute commands. Before forcing the next command to a 
terminal, INIT waits until the terminal output buffers are empty and 
the job is in the keyboard wait state. Therefore, it is advantageous 
to force commands to a terminal which generates output at the highest 
speed since that terminal's output buffers empty faster. Note, in the 
example, that keyboard 4 is established as a VT05 whose default output 
speed is 300 baud. The interface speed is the important factor since 
it is not necessary that a terminal actually be connected to the 
interface unless a visual record of the start up procedure is desired. 

In the case of INIT running as a result of a system crash, it is 
important that commands be executed to obtain crash dump information. 
To discover the cause of a system crash, the system manager can specify 
that INIT run the crash analysis program ANALYS. The following 
commands inserted in the CRASH. CTL file ensure that the analysis 
occurs. 



LOGIN KB4 
FORCE KB4 
FORCE KB4 
FORCE KBh 



[1,5] 

RUN $ANALYS 

[0,1] CRASH. DMP 



For more information on ANALYS, see Section 5.8. 

The system manager can specify commands to be executed on KB0: 
even though INIT runs at the console terminal. The system assigns 
job number 1 to INIT since it is the first job to run at start up 
time. Because INIT runs at the console terminal, commands forced 
to KB0: are not executed until INIT terminates. To prevent premature 
termination, INIT does not allow a CTRL/C combination to be forced 
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to the console terminal. Therefore, the user must not specify the + 
character in a FORCE command on the console terminal. 

If the system manager wishes to run a certain job as job number 1, 
he can specify the proper commands to the console terminal. For 
example, it is often desired to run the ERRCPY system program as 
job 1. The following command in the control file ensures this action. 

FORCE KBJ3: RUN$ERRCPY 

ERRCPY runs and detaches immediately after INIT terminates as the 
result of the END command. 

5.1.2.1 START. CTL File Example - The following is an example of a 
START. CTL file which sets' keyboards 1 and 2 and runs the ERRCPY program. 

MOUNT DK1:PRIV1 

MOUNT DK2:PRIV2 

LOGINS 

LOGIN KB1: [1,2] 

FORCE KB1: RUN $TTYSET 

FORCE KB1: KB1 : 

FORCE KB1: VT05 

FORCE KB1: KB2 : 

FORCE KB1: LA30S 

FORCE KB1: EXIT 

FORCE KB0: RUN $ERRCPY 

SEND RSTS IS NOW ON THE AIR . . . 

END 

5.1.2.2 CRASH. CTL File Example - The following is an example of a 
CRASH. CTL file which runs the appropriate programs to recover crash 
information and initializes the system for time sharing. 

MOUNT DK1:PRIV1 

MOUNT DK2:PRIV2 

SEND RSTS RECOVERING FROM A CKAsH... 

LOGINS 

LOGIN KB1: [1,2] 

FORCE KB1: RUN 4TTYSET 

FORCE KB1: KB1 : 

FORCE KB1: VT05 

FORCE KB1: KB2 : 

FORCE KB1: LA303 

FORCE KB1: EXIT 

FORCE KB1: RUN $ANALYS 

FORCE KB1: 

FORCE KB1: ANALYS.TMP 

FORCE KB1: RUN $ERRCRS 

FORCE KB1: ERRORS. TMP 

FORCE KB I: 
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FORCE KB1: RUN $ERRDIS 

FORCE KB1: ERRCRS.TMP 

FORCE KB1: ERRDIS.TMP 

FORCE KB1: ALL/S 

FORCE KB1: ALL 

FORCE KB1: /K 

FORCE KB1: BYE 

" ' FORCE KB1 : YES 

FORCE KB0: RUN $ERRCPY 

SEND RSTS IS NOW ON THE AIR. . 

END 

5.1.2.3 Simplified CRASH. CTL File Example - The following is an 
example of a CRASH. CTL file which demonstrates how INIT can run itself 
and therefore initialize the system for time sharing. 

SEND RSTS RECOVERING FROM A CRASH... 

LOGINS 

FORCE KB1: SET VT05 

LOGIN KB1: [1,2] 

FORCE KB1: RUN $ANALYS 

FORCE KB1: 

FORCE KB1: ANALYS.TMP 

FORCE KB1: RUN $ERRCRS 

FORCE KB1: ERRCRS.TMP 

FORCE KB1: 

FORCE KB1: RUN $ERRDIS 

FORCE KB1: ERRCRS.TMP 

FORCE KB1: ERRDIS.TMP 

FORCE KB1: ALL/S 

FORCE KB1: ALL 

FORCE KB1: /K 

FORCE KB0: RUN $INIT 

END 



5.2 PERFORMING SYSTEM SHUT-DOWN 

The shut-down procedures for the RSTS- 11 system are the most 
critically important after the system generation procedures. If 
system shut-down is not conducted in an orderly and careful fashion, 
much valuable user data can be irretrievably lost. It is, therefore, 
strongly suggested that the system manager enforce rigid adherence 
to the proper shut-down procedures. 

To fully understand shut-down procedures, knowledge of other 
RSTS- 11 system procedures is necessary. Before implementing the 
procedures described in this section, the system manager must 
familiarize himself with the concepts presented elsewhere in this 
chapter under the titles "On-Line System Control", "Disk Management", 
and "Monitoring System Status". 
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The following steps are mandatory for readying the system for 
orderly shut-down procedures. All further logins must be disabled 
by use of the NO LOGINS command of UTILTY. The system manager does 
not want new users entering the system when shut-down procedures 
are being initiated. All non-system disk devices must be locked to 
prevent files from being opened on them. -The system manager does 
this by using the LOCK command of UTILTY. For the same purpose, the 
system manager must assign all other devices (by the ASSIGN system 
command) to his job. This action ensures that users already logged 
into the system do not initiate further processing on a device. 

When all system resources are prohibited from further use, the 
system manager must next advise users that shut-down procedures are 
in effect. The SEND command of UTILTY is the means to accomplish 
transmitting, the advice. The user should be informed that he has a 
certain length of time to close all his files, deassign all his 
devices and log off the system. 

The system manager next monitors system status to determine 
what devices have been freed. When an assignable device is no longer 
assigned or initialized, he uses the ASSIGN command to make it un- 
available to other users. If a disk device has no open files, the 
system manager can logically dismount the disk using the UTILTY 
system program command DISMOUNT. (In no case is the system disk 
dismounted, however.) 

When all devices have been assigned to the system manager's job 
and all disks (except the system disk) have been logically dis- 
mounted, the system manager next ensures that no jobs are active 
except his own. He does so by requesting a job status report via 
the SYSTAT system program. If all jobs are logged out (except the 
system manager's), if all non-system disks are logically dismounted, 
and if further logins are disabled, the system manager can safely 
proceed to shut down the system. 

The above conditions being true, the system manager shuts down 

the RSTS-11 system in the following way. He logs his job off 

the system. (The BYE command automatically deassigns all the 

devices assigned to a user's job number.) When the printing of 

LOGOUT messages is completed, and the Teletype is idle, the system 

shut-down is effected by moving the CPU ENABLE/HALT switch to its 

HALT position. Alternatively, he can use the SHUTUP system program 

which logs his job off the system and, additionally , brings the system 

to an orderly halt at address 54. 

5-9 January 1973 



It can be seen, from the above discussion, that it is necessary 
to establish administrative procedures governing RSTS-11 system 
operational hours. All users can be kept informed by means of the 
NOTICE.TXT file which prints out when a user successfully logs into 
the system. System shut-down times are to be considered fixed so 
that users can plan a work load and properly complete their processing 
within the allotted hours of scheduled operational time. Erratic 
system shut-downs are guaranteed to cause unhappy users. 

5.3 SYSTEM UTILITY OPERATIONS - UTILTY 

On-line system control and disk management operations are 
performed by using the commands of the UTILTY system program. UTILTY 
is a required system program and should be stored in its compiled 
form in the system library (account [1,2]). While operating with 
the facilities of the UTILTY system program, the system manager has 
on— line system control and can perform such operations as: 

(a) Enable and disable logins. 

(b) Send messages to and force text strings to any or 
all keyboards on the system. 

(c) Terminate execution of a job (kill) or cause a 
remote line to hang up . 

(d) Set and reset system date and time. 

The system manager also can perform various disk management operations 
such as: 

(a) Cause private disk packs to be used or to be pro- 
hibited from use on specified disk drive units 
(mount and dismount operations) . 

(b) Prohibit or allow creation and accessing of files 

WAA P^C^J-i-AgU UXSJ\ V^-U J_ V 1^ UUAV,W VJ..-IW1.. M .. M t~~ . ~. v *- .. * 

operations) . 

(c) Rebuild the storage allocation table on a corrupted 
disk (clean operation) . 

(d) Change the number of blocks of disk storage an 
account can retain at LOGOUT time (quota) and 
change an account password. 

(e) Remove all files from a user's account on a 
specified disk drive unit (zero operation) . 
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The commands of the UTILTY system program are presented in 
Table 5-2 for reference. The following three sections explain the 
necessity of the commands according to their functional uses: 
program control, on-line system control, and disk management. 

5.3.1 Invoking and Terminating UTILTY 

The system manager or a privileged user executes the UTILITY 
system program by typing the following command while logged in at 
any terminal. 

RUN $UTILTY 

The program responds by printing one header and one query line as 
follows: 

'UTILTY' SYSTEM UTILITY PROGRAM 



after which any valid command can be specified. A list of all valid 
commands is printed if the HELP command is typed. The query line 
need not be present in order to type in any subsequent commands. 
When no commands are pending, the program prints the ? character. 

Termination of the UTILTY system program can be properly 
accomplished by typing either CTRL/Z or the EXIT command. (CTRL/Z 
is echoed by +Z being printed on the keyboard printer.) If CTRL/Z 
is typed at any time, the operation currently being performed is 
properly completed; and control is returned to the BASIC-PLUS 
editor. The completion of the UTILTY run is signalled by READY being 
printed at the keyboard. If the EXIT command is typed, all currently 
pending commands are executed; and control is returned to the BASIC- 
PLUS editor (signalled by READY) . 

If CTRL/C is typed in order to terminate the program run, any 
operation in progress is interrupted immediately. Control is 
returned to the BASIC-PLUS editor. (CTRL/C is echoed at the keyboard 
printer by +C being printed.) Typing CTRL/C to terminate a UTILTY 
program run is not considered proper termination since the effect 
of uncompleted internal system operations is unpredictable. The 
system, manager is advised to use CTRL/Z or the EXIT command to 
terminate UTILTY. 
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Table 5-2 



UTILTY System Program Commands 



Category 



Command and 
Format 1 



Use 



Operational 
Control 



LOGINS 



NOuLOGINS 



SENDi_j 



|KBn7[ . 

[allJ-*'** 



force -[a?l]- xxx 



KILLujn 



HANGUPi—iKBn: 



DATEi_idd-mon-yy 



TIME,_,hh:mm 



Enables users to login to the 
RSTS-11 system. 

Prevents further login attempts, 



Causes the text string xxx to 
be printed on the keyboard 
unit n or all keyboards. 

Causes the text string xxx to 
be forced into the keyboard 
unit n or all keyboards as if 
it had been typed in. 

Immediately terminates user 
job specified by n. 

Disconnects the remote line 
specified by KBn: from the 
dataset port. 

Sets the RSTS-11 system date to 
the value of day, month and 
year (for example, 13-NOV-72) . 

Sets the RSTS-11 24 hour clock 
to the value of hours and 
minutes (for example, 21:52 
means 9:52 p.m.) . 



Disk 
Management 



MOUNTudev : id 



DISMOUNTujdev: 



Logically associates the disk 
residing on the disk drive unit 
specified by the device designator 
dev: with the pack identification 
label (id) so that data on the 
disk can be properly accessed by the 

MOUNT DK1:PRIV1 



j associates the pack PRIV1 with 
the physical device designator DKl 



Disassociates a disk pack from 
its physical drive specified 
by dev:. Must be used prior 
to removing the cartridge from 
the disk drive unit. 



J The notation 



indicai 



that a space character is required. 
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Table 5-2 (Cont.) 
UTILTY System Program Commands 



Category 


Command and 
Format 1 


Use 


Disk 

Management 
(Cont.) 


LOCKi_idev: 


Places the disk drive unit 
dev: in a state which prevents 
files from being OPENed. 




UNLOCKi_jdev : 


Allows users to OPEN files on 
disk drive unit dev:. 




CLEANi_idev : 


Rebuild the SAT (Storage 
Allocation Table) of the pack 
mounted and locked on disk 
drive unit dev:. To be used 
only when message DEVICE NEEDS 
CLEANING is printed. 




QUOTA i_,[n,m]i_jq 


Sets the quantity of 2 56-word 
blocks the user account [n,m] 
is allowed, to retain at 
logout time to the decimal 
number q. A value for q of 
zero means unlimited quota. 




CHANGEutnjm] passwd 


Alters the password of user 
account [n,m] to the 6- 
character alphanumeric passwd. 




ZEROi_jdev: [n,m] 


Deletes all files from user 
account [n,m] on the disk drive 
unit specified by dev:. 


Program- 
Control 


HELP 


Prints a list of valid UTILTY 
commands at the keyboard 
printer. 




CTRL/C 


Peremptorily terminates execu- 
tion of the current operation 
and the UTILTY run. 




CTRL/Z 


Allows completion of current 
operation before termination 
of the UTILTY run. 




EXIT 


Allows completion of pending 
operations before termination 
of the UTILTY run. 



'The notation i_j indicates that a space character is required. 
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5.3.2 Principles of Disk Management 

Certain commands of the UTILITY system program are used to 
properly accomplish, the management of disks on the RSTS-11 system. 
Such commands are presented for reference in Table 5-2 under the category 
of disk management. To more easily convey the proper use of indi- 
vidual disk management commands, the following description of each 
command is presented with a discussion of its function and value. 

5.3.2.1 Preparing a Disk for Use on a Drive - A disk pack or cartridge, 
to be effectively used on the RSTS-11 system, must be made known to the 
system. The disk is made known to the system by associating its logical 
name, the pack label or id, with the physical device unit number on 
which the disk resides. Such a process is called mounting and is 
effected by the MOUNT command. 

The MOUNT command requires a specific device designator and the 
exact pack label or identification (id) on the disk which is to 
be mounted on the system. A new disk is prepared for use on the 
RSTS-11 system by initialization with the DSKINT program. A disk pack or 
cartridge, when initialized, is assigned a unique 6-character 
alphanumeric name called the pack label or id. See Chapter 6 for 
a description of disk initialization. 

When the RSTS-11 system is initialized, at start-up time, only 
the system disk is mounted. As is described in the discussion of 
controlling system start-up, the system manager must, ensure that 
other packs in the public structure or private structure are mounted 
by directives from the START. CTL or CRASH. CTL file used by the 
INIT system program. The same principle applies to disks added to 
the system after system start-up. Thus, the system manager mounts 
a disk on the system by means of the UTILTY system program MOUNT 
command . 

The MOUNT command of UTILTY does not perform two other opera- 
tions which the MOUNT command in the control files performs and 
which are necessary before the disk can be safely used. First, 
the SAT (Sector Allocation Tables) in the SATT.SYS file of the disk 
device MFD must be rebuilt if necessary. (The message DEVICE NEEDS 
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CLEANING is printed if the SAT requires rebuilding.) The operation 
of rebuilding the SAT is called cleaning the disk. The disk must 
be cleaned if, at the last time the disk was mounted, the SAT being 
manipulated in core during the file processing, was not placed back 
in the SATT.SYS file of the disk MFD, thus corrupting the SATT.SYS 
file. The corruption condition results, for instance, when a user 
physically removes an operational disk from a drive unit without 
performing the proper logical dismounting of the disk. When 
corruption occurs, the amount of storage actually occupied on the 
disk as a result of file processing is not reflected in the SAT 
of the SATT.SYS file.. Storage occupied is not always reflected in 
the SATT.SYS file because SAT's (storage allocation tables) are 
manipulated in core individually and are not written back to the 
disk to update the SATT.SYS file until the file is CLOSEd. 

The system manager, when physically placing a disk in a 
drive unit, must rebuild the corrupted SAT by using the CLEAN command 
of the UTILTY system program. Before the clean operation on a disk 
can proceed, the disk must be in a state which ensures unavailability 
for normal usage (opening of files) . Such a state is termed the 
locked state. When the disk device is in the locked state, no user 
except a privileged user can open files on that disk device. 

It is therefore necessary, before a clean operation is to be 
performed, to make the disk device unavailable to users. The system 
manager makes the device unavailable by use of the LOCK command of 
the UTILTY system program. After the action of the LOCK command is 
completed, the system manager then initiates the clean operation by 
use of the CLEAN command. 

Once the clean operation is completed, the system manager can 
safely make the disk available to users of the RSTS-11 system. He 
accomplishes this by use of the UNLOCK command. Once a disk device 
is placed in the unlock state by the UNLOCK command, users are 
allowed to open files on the disk. 

Before a disk pack or cartridge can be properly removed from a 
drive unit, actions similar to those of preparing the disk for use 
must be employed. For example, if the system manager desires to 
replace a private pack with another private pack, he must follow a 
careful procedure. (Under no circumstances should a public pack be 
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removed from the system during normal system operation.) First, he 
must ensure that no files are open on the drive unit. The system 
manager can do this by requesting a disk status report through the 
SYS TAT system program, which is described in Chapter 4 of the 
RSTS-11 System User's Guide . His next action would be to lock the 
device unit by use of the LOCK command. ' This action ensures that 
no more files are opened on the disk pack. 

When the disk pack to be removed from the drive unit has no 
OPEN files and has been LOCKed, the system manager next must dis- 
associate that disk pack from the drive unit. He does so by logically 
dismounting the device with the DISMOUNT command. After the dis- 
mounting action is completed, the disk pack can safely be removed 
from the drive unit. Any pack which is to replace the pack removed 
must undergo the procedures previously described for proper use of 
the pack. These procedures are summarized . in Table 5-3. 

5.3.-2.2 Removing Files from an Account - Before an account can be 
deleted from the RSTS-11 system or deleted from a private pack, the 
account must contain no files. The ZERO command of UTILTY enables 
the system manager to remove all files from an account on a device. 

5.3.2.3 Changing Quota and/or Password of an Account - Each user 
account in the RSTS-11 system has associated with it a quota of 
disk storage that the account can retain at logout time and a pass- 
word which allows access to the system. The quota and password 
are specified by the system manager when the account is created. 

command of UTILTY. The system manager specifies, in the QUOTA 
command, the account number and the decimal number of 256-word 
blocks of disk storage he wishes the account to be able to retain 
at logout time. If he specifies zero for the quota, he allows the 

.__,.-_.!_ — — i j— *•: j-~,3 m<n4--^ ^ -P Ki AnVp 
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The system manager can change the password of an account by 
using the CHANGE command. 
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Table 5-3 



Procedures for Using Disk Packs 



Enter a Pack to the System* 


Remove a Pack from the System 


1. Use the SYSTAT system pro- 
gram to ensure that the 
drive unit is free. 

2. Place the pack in the drive. 
When the drive is READY, 
write enable it. 

3. Invoke the UTILTY system pro- 
gram and use MOUNT command 

to notify system of new pack. 

4 . Use CLEAN command if 
necessary. 

5 . Use UNLOCK command to free 
device for use. 


1. Invoke UTILTY and use LOCK 
command' on the drive unit 
containing the pack to be 
removed . 

2 . Use SYSTAT disk status re- 
port to determine the number 
of OPEN files. If zero, 
proceed. If non-zero, wait 
until all files are closed 
before proceeding. 

3. With no files open on the 
device unit, use the 
DISMOUNT command to notify 
system that the pack is 
being removed.. 

4 . Remove pack from disk drive 

unit. 



*The disk pack is assumed to have been initialized and formatted using 
the DSKINT stand-alone program. See Chapter 6 for a description of 
the DSKINT program. 

5.3.3 Operational Control of the System 

Certain commands of the UTILTY system program control the opera- 
tion of the system. Such commands are listed for reference in Table 
5-2 under the category of operational control. These commands and 
examples of their possible usage are described in this section. 



When the system manager is on-line in the RSTS-11 system, he 
can monitor and control system operations . By use of the SYSTAT 
system program (described in this chapter and in Chapter 4 of the 
RSTS-11 System User's Guide ) , he observes the number of free small 
buffers. If, for example, the number of free small buffers drops 
below 10, system efficiency declines. He can remedy the possible 
degradation of system efficiency by preventing more users from 
logging into the system. The system manager prevents further logins 
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by using the NO LOGINS command. The system manager also uses the 
HO LOGINS command in preparing to shut down time sharing operations 
of the PDP-11 computer. 

The system manager can communicate with a user at his terminal 
or with all users by the SEND command. The SEND command causes a 
specified text string to be placed in the output buffer of a terminal 
or all terminals and, as a result, be printed on the terminal key- 
board printer. If a user assigns a peripheral device for an in- 
ordinately long time, for example, the system manager can transmit 
a message requesting the user to deassign the device. By specifying 
ALL in place of the device designator of a single keyboard, the 
system manager can transmit the message to each on-line terminal in 
the RSTS-11 system. 

If it becomes necessary, during the course of system operations, 
to. handle troublesome users, the system manager has two capabilities. 
He can cause a user's terminal (or all users' terminals) to receive 
a text string by the FORCE command. He can also terminate a user's 
job by the KILL command. The FORCE command places a text string 
in the input buffer of a specified terminal. If the first char- 
acter of the text is the up-arrow character (+) , it is replaced 
by a CTRL/C (-tC) . The following sequence of two FORCE commands 
causes a user's terminal to receive two command strings, which, 
when executed, log the user's job out. 

?FORCE KB4 : +BYE 
?FORCE KB4: YES 

The KILL command peremptorily terminates a user's job. No 
files are retained, and none of the normal housekeeping functions are 
performed. The user is immediately logged off the system. 

If the system manager determines that a dataset line is in use 
but no keyboard activity is taking place (by SYSTAT job status 
report) , he can disconnect the dataset. The HANGUP command causes 
the remote line specified by KBn: to be disconnected. The hangup 
capability prevents a user from monopolizing the line without being 
charged for connect time and frees the line for other remote line 
users. 
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The DATE and TIME commands allow the system manager to set the 
system date and the value of the 24-hour clock, respectively. 

5.4 CREATING AND DELETING USER ACCOUNTS - REACT 

The system manager or a privileged user creates and deletes 
system accounts by use of the REACT system program. (The creation 
and deletion of user accounts can be programmed by a privileged 
user with the SYS system function FIP codes of and 1, respectively. 
See Chapter 4 for a description of the SYS system function.) The 
REACT system program enters user accounts on and deletes user 
accounts from the system device in the public structure or individual 
disk devices in the private structure. 

The REACT system program should be stored in its compiled form 
in the system library account [1,2]. REACT is called by using the 
RUN command as is shown below. 

RUN $REACT 

REACT responds by printing the following message which requests that 
the user specify a function. 

'REACT' SYSTEM ACCOUNT MANAGER 
FUNCTION ? 

The three valid functions are described in Table 5-4, and explained 
in the following sections. 

5.4.1 Creating Individual Accounts - ENTER Function 

The ENTER function creates individual user accounts in the MFD 
on the system device or on a disk device in the private structure. 
When the system manager runs REACT, he invokes the ENTER function 
by typing E in response to the request for a function. Upon recogni- 
tion of the E response, REACT prints a series of questions. A 
response to each question must be typed by the user before the 
appearance of the next question. The questions are explained in 
Table 5-5. 
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Table 5-4 



REACT System Program Functions 



Function 


Abbreviation 


Purpose 


ENTER 


E 


To enter individual accounts on 
system device in the public 
structure or a disk device in the 
private structure. 


DELETE 


D 


To delete individual accounts from 
the system device in the public 
structure or from a disk device in 
the private structure. 


STANDARD 


S 


To create standard user accounts 
on the system device from the 
ACCT.SYS file at system generation 
time . 



The following is a sample dialogue for the ENTER function. 



RUN $REACT 

'REACT' SYSTEM ACCOUNT MANAGER 

FUNCTION? E 

PRO J, PROG? 100,100 

DISK: PASSWORD? DK1 : DEMO 

QUOTA? 5000 

CLUSTER SIZE? 

PRQJ,PR0G? tC 



READY 



If the system manager enters an account in the MFD of a disk 
within the private structure, he permits the owner of the account 
to create files on that disk. Prior to using REACT to create an 
account on a private pack, the pack must be mounted and placed in 
the unlock state by means of the UTILTY system program. Refer to 
the discussion under the title "Disk Management" in this chapter. 

If the system manager enters an account in the MFD of the 
system disk, he permits the owner of that account access to the 
RSTS-11 system and allows the owner of that account the use cf 
storage space within the public structure. It is suggested that 
when a new account is created, the system, manager also place an 
entry for the new account in the ACCT.SYS file. Refer to the dis- 
cussion of the STAND7*RD function of REACT. 
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Table 5-5 



Responses to ENTER Function Queries 



Question 


Response Format 


Meaning 


PRO J, PROG? 


n,m 
CTRL/C 


The user account number to be 
entered in the MFD, where 
K=n<=254 and 0<=m<=254. 

The user terminates the dialogue 
and REACT by typing the CONTROL 
key and C combination simultane- 
ously. 


DISK: PASSWORD? 


passwd 
device ipasswd 


To enter a password for an account 
on the system device MFD, where 
password is from 1 to 6 alpha- 
numerics. No value for DISK need 
be specified since the system. 
disk is assumed. 

To enter a password to an account 
on a device in the private 
structure, where device is the 
device designator and passwd is 
from 1 to 6 alphanumerics . For 
example : 

DK1:PASS 

DK1 must be logically mounted and 
in the unlock state by means of 
the UTILTY program prior to in- 
voking REACT. 


QUOTA? 


n 


The number of 256-word blocks of 
disk storage the user account is 
allowed to retain at LOGOUT time 
where J3<=n<=65 ,535 and JZf means 
no quota- is imposed upon the 
user's account. Therefore, a 
value of allows the user account 
unlimited disk storage retention. 


CLUSTER SIZE? 


n 


The account UFD cluster size where 
n is 0,1,2,4,8, or 16. If is 
specified, the pack cluster size 
is used. If non-zero the value 
for n must be at least the pack 
cluster size. Cluster sizes of 
1,2, or 4 are recommended for 
most systems. 
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5.4.2 Deleting Accounts - DELETE Function 

The DELETE function deletes individual user accounts from the 
MFD of the system device or from the MFD of a disk device in the 
private structure. As in the case of the ENTER function, a disk 
device in the private structure must be logically mounted and in 
the unlock state prior to deletion of an account. In addition, 
before an account is deleted from an MFD, whether on the system 
device or on a disk device in the private structure, the UFD of that 
account to be marked for deletion must contain no files. To clear 
an account's UFD of files, the ZERO command of the UTILTY system 
program or the /ZE switch of the PIP system program must be used. 
See the description of the UTILTY system program in this chapter and 
of PIP in Chapter 4 of the RSTS-11 System User's Guide . 

The DELETE function is invoked by typing D in response to the 
request for a function. The REACT program prints a series of 
questions. A response to the question must be typed by the user 
before the next question appears. The questions are explained in 
Table 5-6. 

Table 5-6 
Responses to DELETE Function Queries 



Question 


Response Format 


Meaning 


PRO J, PROG? 


n,m 

nmriT //i 


The user account number to be 
deleted from the MFD. 

The user terminates the dialog 
and REACT by typing the CONTROL 
key and C key combination 

simultaneously. 


DISK? 


null 
device: 


By typing the RETURN key, the 
system device is specified. 

The device designator of a disk 
in the private structure. For 
example : 

DK1: 

The disk must be logically mounted 
and in the unlock state by means 
of the UTILTY system program 
prior to invoking REACT. 
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The following is a sample dialog for the DELETE function. 

RUN $REACT 

'REACT' SYSTEM ACCOUNT MANAGER 

FUNCTION? D 

PRO J, PROG? 100,100 

DISK? DK1: 

PRO J, PROG? +C 

READY 

~5 . 4 . 3 Automatic Creation of User Accounts - STANDARD Function 

The STANDARD function in the REACT system program is present to 
facilitate automatic creation of a large number of user accounts at 
system generation time. Explanation of the STANDARD function is 
presented in detail in two sections of Chapter 2 of this manual: in 
the overview of system generation section and in the procedural steps 
for system generation section, under like subsection titles 
"Establishing System Accounts". A few ancillary remarks are made 
here. 

The ACCT.SYS file is created by PIP as shown in the sample 
dialog in the procedural steps for system generation section of 
Chapter 2. The file ACCT.SYS is stored in the system library account 
[1,2]. ACCT.SYS is an ASCII text file, each line of which is for- 
matted with the following: the items which would be specified by 
the user in response to the questions of the ENTER function and a 
name item. Each line of the file represents a single account to 
be created. The general format is as follows. 

pro j , pr og , pa s swd , quota , cluster , name 

The items proj , prog, passwd, quota, and cluster are described under 
the ENTER function. The last item, name, is a user-specified 
additional designation of the account which is used by the GRIPE 
system program and which is ignored by REACT. The item, name, must 
contain no commas, single quotes, or double quotes. The accounts 
[1,1] and [1,2] can appear in the ACCT.SYS file although they have 
been created previously during the REFRESH action of the system 
generation procedure. These account entries in ACCT.SYS are only 
used by the GRIPE system program. 
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It is suggested that the system manager devise a program to add 
the new account information to the ACCT.SYS file each time he creates 
new accounts by the ENTER function. By updating the ACCT.SYS file, 
he enables users of new accounts to be identified to the GRIPE 
system program. The absence of the account information in the 
ACCT.SYS file does not hinder the operation of the GRIPE program, 
however . 

The system manager can manually enter new account information 
to the ACCT.SYS file by using the append feature of PIP as follows. 

RUN $PIP 

PIP -RSTS V4A-12 SYSTEM #213 

*$ACCT.NEW<$ACCT.SYS,KB: 

100, 100, DEMO, 100,1, GENERAL USE 

tz 

I&ACCT.SYS/DE 

^$ACCT . SYS=$ACCT . NEW/RE 

* + Z 

READY 

5.5 PERFORMING SYSTEM ACCOUNTING OPERATIONS - MONEY 

The MONEY system program enables the system manager to extract 
system accounting information for all accounts in the system or 
for selected accounts. MONEY is an optional system program and can 
be run by a non-privileged user to obtain his own account information 
(excluding password) . Refer to Chapter 4 of the RSTS-11 System User's 
Guide for a description of MONEY for a non-privileged user. MONEY 
is stored in its compiled form in the system library account [1,2] 
with a protection of <40>. 

MONEY is called by typing the following command while logged 
into the RSTS-11 system. 

RUN $MONEY 

If the caller is a privileged user, a sequence of option queries 
is printed at the keyboard. Typing an answer to one query causes 
the next one to be printed. The queries and the explanation for 
each is given in Table 5-7. The accounting data given as output 
for each account is presented in Table 5-8. 
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Table 5-7 



MONEY System Accounting Program Options 



Option Query 


Reply 


Explanation 


OUTPUT DEVICE? 


dev : filename . ext 


A file structured or non-file 
structured device can be 
specified. For example: 

LP: 




Typing only the 


Output is printed at the 




RETURN key 


logged-in keyboard printer. 


PRINT PASSWORDS? 


NO 


Typing anything except NO 
causes passwords to be printed. 


RESET? 


YES 


Typing anything except YES 
causes the accumulated 
accounting data to be pre- 
served. Typing YES causes the 
following items to be reset 
to zero. 

CPU-TIME 

KCT's 

CONNECT 

DEVICE 

ACCESS 


DISK? 


DKn: 


Type the disk device desig- 
nator with unit number n to 
select the accounting data 
from a private pack. 




Typing only the 


The accounting data selected 




RETURN key. 


is for all public disks. 


SELECTIVE? 


YES 


Typing anything except YES 
causes accounting data for all 
accounts (on the private pack 
or on the system, whichever 
the reply to the DISK? query 
indicates) to be dumped. 

Typing YES causes an additional 
query ACCOUNT? 
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Table 5-7 (Cont.) 



MONEY System Accounting Program Options 



Option Query 


Reply 


Explanation 


ACCOUNT? 


n,m 


The account query appears if 
the reply to the SELECTIVE? 
query is YES. Accounting data 
is dumped for the account 
specified by the project- 
programmer number [n,m] , 
following which, the query is 
repeated . 




CTRL/C 


Typing CTRL/C or CTRL/Z 




CTRL/Z 


terminates the program run. 



The MONEY system program can be run during normal time-sharing. 
No conflict arises if the system attempts to update a user's 
accounting information while the MONEY is accessing it. When the 
RESET option is used, MONEY reads and resets to zero the user's 
accounting information before any system action can update the values 
being read and reset. Thus, no user accounting information is lost. 

Some of the items output can be used to weight billing or 
evaluate usage. The item KCT, in effect, reflects system usage 
more accurately than the CPU-TIME item. For example, two users may 
each exhaust one minute of CPU-TIME in an accounting period. 
However, one user may tie up 2K words of core while the other may 
occupy 6K words of core each time he runs. The first user's KCT 
value is incremented by 2 for each tenth of a second his 2K job 
occupies core. While the 2K user runs, it is possible for two other 
2K user jobs to be running. With the 6K user, each tenth of a second 
he runs, his KCT value is incremented by 6. The 6K user is tying up 
more system resources and this is reflected in his higher KCT value. 
Thus, a user's average job area can be gained by dividing the number 
of KCT's reflected for the accounting period by the number of tenths 
of seconds derived from the value of CPU-TIME, Referring to 
the example of values in Table 5-8, user [100,100] average job 
size of 3.6K is computed by dividing the number of KCT's, 3000, by 
the number of tenths of seconds derived from CPU-TIME, 832. 
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Table 5-S 



MONEY System Accounting Program Output 



Header 






Description 


Meaning 


Example 


ACCT 


Project-programmer 
number (account) 


100,100 


PASSWORD 


Account password 
given at login time 


FOO 


CPU-TIME 


Number of hours :minutes : 


1:23.2 (one minute, 




second .tenths of a 


23.2 seconds) 




• second of processor time 






the account has used 






since the last reset. 




KCT's 


Core usage factor (kilo- 
core-ticks) . One KCT is 
the usage of IK of core 
for one tenth of a 
second. 


3000 


CONNECT 


Number of hours and 


2:34 (2 hours, 34 




minutes (hh:mm) of 


minutes) 




terminal connect time. 




DEVICE 


Number of hours and 
minutes (hh:mm) of de- 
vice usage time, ex- 
cluding public disks. 


20 (20 minutes) 


ACCESS 


Number of logins and 


8 7 (8 logins. 




1 ncrnii t* *? 


7 logouts) 


DISK 


Number of 256-word 
blocks of disk storage 
allocated. 


100 


QUOTA 


Number of 256-word 
blocks the account is 
allowed to retain at 
logout time . 


500 


(no header) 


UFD cluster size 


2 
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The value under the header description DISK reflects the 
actual number of blocks tied up in file allocation on disk. It is 
not the same value reported by the CATALOG system command. A file 
may occupy 1 block on a disk as reflected by the CATALOG command, 
but tie-up 3 additional. blocks of disk storage if the file cluster 
size is 4 blocks per cluster. In essence, the user is depriving the 
system from claiming those three contiguous blocks in the cluster 
although the user is not currently occupying the space. 

The information given without a header is the UFD cluster size. 
No other system program returns this value which is determined when 
the account is created by the REACT system program. It is provided 
in the MONEY output for information purposes only and has no 
accounting value . 

5.6 MONITORING SYSTEM STATUS - SYSTAT 

During normal time-sharing operations, the system manager 
should monitor the status of the RSTS-11 system. He gains informa- 
tion concerning system status by use of the system program SYSTAT. 
The SYSTAT system program is stored in the system library account 
[1,2] with a protection of <168>. The options and output supplied 
by the SYSTAT system program are described in Chapter 4 of the 
RSTS-11 System User's Guide . The discussion here gives the system 
manager guidelines on how and when to use SYSTAT. 

Several instances of the use of SYSTAT are described in other 
sections of this chapter in conjunction with other system manager 
operations. The previously described instances are listed here. 

(a) During preparation for system shut-down, to determine 
active jobs and disk devices and assignable devices 
in use. 

tl r *'\ T« ^.An -i 11n ^4- -i r\*s T.»i 4-U 4- V\ /^. TTrTiTTTV e^Tcfom nrnrrram r< r\mm ;=> n ^ 
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HANGUP, for determining misuse of a remote line. 

(c) In conjunction with the UTILTY command NO LOGINS, when 
the number of free small buffers is less than 10. 

Refer to the discussion relevant to the individual system program 
or system operation for more information on the above uses of 
SYSTAT. 
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Further uses of SYSTAT are listed below and discussed in the 
ensuing paragraphs. 

(d) Monitoring the occurrence of catastrophic errors by 
the ERROR count. 

(e) Uncovering malfunctioning keyboards by the HUNG TTY 
count. 

(f) Guarding against a disk device filling up by watching 
the FREE block count. 

(g) Following the progress of user jobs or detached jobs 
by the STATE and RUN-TIME items of job status. 

Item (d) is important for system managers whose system does not 
use the crash dump facility. A progressively increasing catastrophic 
error count indicates some user or users are disturbing system 
operations or attempting to abuse system facilities. If pre-planned 
invocation of the ANALYS system program from the CRASH. CTL file is 
not in effect, no accurate method can be used to determine the 
guilty job(s). (Refer to the Section 5.2 for a description of the 
CRASH. CTL file and Section 5.8 for a discussion on analyzing system 
crashes.) 

Each occurrence of a catastrophic error causes the CRASH. SYS 
file to be written. (That is, if the crash-dump facility was 
enabled at system start time.) Successive occurrences of catastrophic 
errors or system crashes cause the CRASH. SYS file to be subsequently 
overwritten. Thus, running the ANALYS program at random only 
supplies information relative to the latest system crash or cata- 
strophic error. Therefore, it is recommended that automatic running 
of the ANALYS system program from the CRASH. CTL file be done. In 
this manner, automatic monitoring of catastrophic errors is provided. 
The system manager is kept aware of occurrences of catastrophic 
errors by the output of the ANALYS system program. 

Item (e) refers to the HUNG TTY count reported in the SYSTAT 
buffer status report. A HUNG TTY count of zero is good. A HUNG TTY 
count of non-zero indicates the presence of a malfunctioning terminal 
or terminals. No easy way exists to diagnose the device or devices 
causing the error count. If the HUNG TTY count appears to increase 
perceptibly, a field hardware specialist should be consulted. 
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The FREE block count mentioned in item (f) reflects the 
apparent number of free blocks in the system and is given in the disk 
status report of SYSTAT. For practical purposes, however, such as 
for allocating a file on the device, all of the free blocks reported 
by SYSTAT may not be usable. A NO ROOM FOR USER ON DEVICE message 
may be generated although SYSTAT reports enough FREE blocks exist. 
The cluster size the file uses or the extent of the file in terms 
of clusters prevents files from fitting on the device desired. For 
example, a file whose cluster size is 16 and whose length is 10 
blocks possibly does not fit on a device which SYSTAT reports to 
have 50 free blocks of file space remaining. The cluster size of 16 
demands that 16 contiguous blocks of free space must exist on the 
device before the file can be allocated to the device. In some 
cases, 16 contiguous blocks simply do not exist on a device. (It 
must be pointed out that RSTS-11 does not allow a file to extend to 
another physical device.) 

A further condition exists for showing NO ROOM FOR USER on a 
device. The UFD of the user is perhaps full and cannot accommodate 
the creation of another file. The UFD cluster size was not made 
large enough when the account was created with REACT. 

The occurrence of jobs being stalled in a resource-sharing 
system is detectable by the means presented in item (g) . If the 
system manager notices that a RUN-TIME value of a job is not in- 
creasing (the value is printed out in a job status report) , it 
indicates that the job is stalled, waiting for an I/O device. One 
user job in the system can ASSIGN a device or keep a device locked 
by having one file open on it. The system manager can determine 
the selfish user job by examining the device status report which 
associates the busy device with the job number of the user controlling 
that device. The system manager can request that the selfish user 
free the device or, if that is not viable, can use UTILTY commands 
to force the guilty job off the system. 

The status of detached jobs is of interest also. If a detached 
job is reported by SYSTAT to be in the KB state (hibernate) , it is 
never eligible for run time. The HB state indicates that the de- 
tached job generated an error or has completed execution. The prob- 
lem of a detached job in the HB state is handled by logging in on 
a keyboard, by using the attach capability of LOGIN and attaching 
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the job to a terminal. Once the detached job is attached to a 
terminal, messages can be printed. 

5.7 DETERMINING TERMINAL AND REMOTE LINE CHARACTERISTICS - TTYSET 
AND CONFIG 

When the RSTS-11 system is created, the default terminal char- 
acteristics of all terminal lines are established as those of the 
ASR-33 Teletype terminal. During the system build procedures, the 
system generation program SYSGEN requires that the system manager 
specify the number of local and remote terminals when giving terminal 
related parameters. The system manager does not specify the types 
of local or remote terminals. Since the RSTS-11 system is designed 
to operate with other type terminals besides the ASR-33' type terminal, 
two programs are provided to allow the system manager and users of 
RSTS-11 to take advantage of characteristics of other terminals 
which are not common to the ASR-33 type of terminal. The two programs 
are the TTYSET and CONFIG system programs. 

TTYSET is the terminal characteristics program of the RSTS-11 
system. TTYSET is required on all RSTS-11 systems and must be 
stored in the system library account [1,2] in its compiled form with 
a protection of <168>. A description of the capabilities and 
commands of the TTYSET system program is presented in Chapter 4 of 
the RSTS-11 System User's Guide . 

By design, the effects of the commands of the TTYSET system 
program are temporary and apply only to the current system initiali- 
zation period. Because of this ingenious design feature, the type of 
terminal attached to a keyboard line on the RSTS-11 system is not 
dependent on the system configuration. The RSTS-11 system operates 
easily with other types of terminals but is built to expect ASR-33 
type terminals on all /lines. It is the responsibility of the system 
manager or the terminal user to specify the characteristics of a 
terminal different from ASR-3 3 type terminals in order to take 
advantage of the characteristics of . the different terminal. 

For example, the system manager can substitute a terminal with 
a higher baud rate than an ASR-33 type terminal on a remote line 
without rebuilding the system. Two methods are available to take 

advantage of the terminal with the higher baud rate (if the remote 
line interface has a programmable baud rate). First, the user at a 
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remote site can dial into the RSTS-11 system at the 110 baud rate 
of the ASR-33 type terminal which RSTS-11 expects. Before beginning 
time-sharing operations, the remote user can set the characteristics 
of his terminal by use of the commands of the TTYSET system program. 
Secondly, the system manager can permanently set the characteristics 
of that remote line to always respond to the type of terminal with 
the higher baud rate by use of the CONFIG system program. CONFIG 
is described in Section 5.7.3. 

In another situation, the system manager can replace an ASR-33 
type terminal on a local line with a different type terminal. Two 
methods are available to take advantage of the characteristics of 
the different terminal. First, the system manager can cause the 
terminal characteristics to be automatically set each time the 
system is initialized by use of the TTYSET privileged feature, the 
KBn: command, from the START. CTL and CRASH. CTL files. See Section 
5.7.1 describing the TTYSET privileged feature and Section 5.7.2 
describing the method of automatically setting local terminal 
characteristics each time the RSTS-11 system is reinitialized. 
Secondly, the user of the local terminal can set the characteristics 
of the different terminal by use of the TTYSET system program. 

As an additional example, the system manager or general user can 
alter individual, discrete characteristics of a terminal by use of 
the commands of the TTYSET system program. 

5.7.1 TTYSET Privileged Feature - KBn: Command 

The system manager sets the characteristics of other terminals 
in the RSTS-11 system by use of the KBn: command. The following 

G.A.CUUM J»C kJ.Cllliw'l.l.O I.J. UUCO v,xj.c U.OO ^i. wnu "^u • ^v"«in***« • — **w ..-j ... _<_».... ...v, it - 3 _— | 

while logged into the system under his privileged account, calls the 
TTYSET system program as follows. 

RUN $TTYSET 

'TTYSET' TERMINAL CHARACTERISTICS PROGRAM 



The program responds with a header line and a question mark char- 
acter (?), which indicates that the program is ready to accept 
commands. If the system manager wishes to set the characteristics 
of a VT05 video terminal at keyboard 3, ne types the following commands 
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^KB3: 
?VT05 



The question mark character (?) on the third line indicates that the 
previous KB3 : and VT05 commands are executed and the program is ready 
to accept another command for keyboard 3 or another KBn: command. 

The system manager can also change the individual characteristics 
of a local terminal. If he desires to limit the line length of the 
terminal at keyboard unit 4, he types the following commands. 

2KB*): 
?WIDTH 30 



As a result of the execution of the above commands, whenever 30 
characters are printed on a line of the terminal at keyboard unit 4, 
a carriage return and line-feed operation is performed. 

5.7.2 Automatic Setting of Local Terminal Characteristics 

The setting of terminal characteristics in the RSTS-11 system 
applies only to the current system initialization. This condition 
allows for replacement of an ASR-33 type terminal with any one of the 
authorized terminals without having to change the system configuration 
and, thus, rebuild the system. Since it is quite bothersome for 
the system manager or a user to set characteristics of local terminals 
each time the system is initialized, ah automatic means is provided. 
(The console terminal ...must always be an ASR-33 type terminal. Also, 
characteristics of remote line terminals are permanently set by the 
CONFIG system program, which is described in Section 5.7.3.) 

The automatic means of setting local terminal characteristics 
is by use of the SET command in the START. CTL and CRASH. CTL files 
used by the INIT system program at system initialization time. 
Refer to the sample START. CTL and CRASH. CTL files and the accom- 
panying description of the use of the FORCE directive with the SET 
command in Section 5.1. 
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5.7.3 Setting Remote Line Characteristics - CONFIG 

A remote line user whose terminal is other than an ASR-33 type 
terminal must set the characteristics of his terminal each time he 
logs into the system if he wants to ensure recognition of the char- 
acteristics of that terminal by the RSTS-11 system. The characteris- 
tics remain set until the telephone is hung up or the line disconnected. 

The CONFIG system program is provided in the RSTS-11 system to 
relieve the remote line user from the necessity of setting the char- 
acteristics each time he dials into the system on a certain remote 
line. The CONFIG system program is optional on the RSTS-11 system 
and need not be stored in the system library. The program source 
can be left as distributed in the RSTS-11 kit. When CONFIG is re- 
quired, it can be read into core by using the RUN command, specifying 
the device designator of the medium on which it is stored, and the 
program name, CONFIG. For example, if the RSTS— 11 kit is DECtape, 
the following command is used. 

RUN DT0: CONFIG 

The CONFIG system program responds by typing a query line which 
requests a remote line number, a comma, and a command, in the 
following manner. 

DC11 LINE (0-N), COMMAND? 

On the same line, the system manager types a line number (not a 
keyboard number) ; a comma; and a TTYSET command which designates 
either a distinct terminal characteristic (TAB or NO TAB, for 
instance) or a set of characteristics for a type of terminal (LA30 r 
for example) . The TTYSET commands are listed in Table 4-9 of the 
RSTS-11 System User's Guide . 

The DCll (or DL11E) line numbers needed in response to a CONFIG 
query line are not the keyboard numbers. The assignment of keyboard 
numbers is done on the basis of local line (KLll-type) interfaces 
and remote line (DCll- or DLllE-type) interfaces. Keyboard number 
(KB0:) is always assigned to the console terminal. The lowest 
keyboard numbers, beginning at 1, are assigned to the local lines. 
The next- hiahest Vevbosrrl numbers are assianed to the DCll-type lines. 
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The highest keyboard numbers are assigned to the DLllE type lines. 
The first remote line assigned a keyboard number, the DCll-type 
line, is line number 0; the second remote line is line number 1, and 
so on, until the remote lines are exhausted. These remote line 
numbers are the numbers to be used to reply to the CONFIG query line. 

The query line is repeated after the previous line is executed. 
When no more remote lines and characteristics are to be given, the 
program run is terminated by typing the EXIT command in response to 
a query line. 

The following example demonstrates the use of CONFIG. 

RUN PR .-CONFIG 

DC11 LINE (0-N), COMMAND? 0,LA30S 

DC11 LINE (0-N), COMMAND? EXIT 

READY 

In the above example, CONFIG is run from a DEC supplied paper tape 
through the high speed paper tape reader (PR:) . The system manager 
specifies that the characteristics of remote line are to be those 
of the serial DECwriter, LA30S. The program run is terminated by 
typing the EXIT command in response to the next query line. Control is 
returned to the BASIC-PLUS editor, indicated by the READY message. 
As a result of the above sample run, the characteristics of remote 
line are permanently changed to those of the LA30S . Whenever the 
RSTS-11 monitor responds to the ring signal on remote line 0, it 
restores the characteristics for that line to those of an LA30S serial 
DECwriter. One caution is in order. The DLllE-type interface does 
not have programmable baud rates (speeds) . Therefore, the user must 
not use commands to change baud rates on a remote line having a 
DLllE interface. 

5.8 ANALYZING SYSTEM CRASHES - ANALYS 



When a system crash occurs in RSTS-11, time-sharing operations 
are halted. If the required conditions described in Chapter 3 are 
met, the contents of core are written into the CRASH. SYS file in the 
system account [0,1] and the system is rebooted into core in auto- 
restart mode. However, if a catastrophic error occurs, time sharing 
operations are suspended momentarily. If the No Fail module is 
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present' in the system and if the required conditions are again met, 
certain volatile job information is captured and a request to copy 
all of core into the same CRASH. SYS file is made and time sharing 
operations are resumed. 

The CRASH. SYS file is dynamic and the information it contains 
can be lost. The occurrence of a crash or a catastrophic error 
subsequent to an initial one causes the CRASH. SYS file to be over- 
written. Therefore, the system manager is provided with a means of 
retaining information in the CRASH. SYS file. This means is the 
ANALYS system program. ANALYS is an optional privileged system 
program which is stored in its compiled form in the system library 
account [1,2] with a protection of <168>. The use of the ANALYS 
system program to document system crashes requires that the CRASH. SYS 
file be created at system start-up time and that the crash dump 
feature be enabled at system start-up time . 

The ANALYS system program is invoked by the following command: 

RUN $ANALYS 

In response, two successive query lines are printed as follows: 

INPUT? 
OUTPUT? LP: 

The first query line requests a filename of the file to be 
analysed, which by default is CORE. SYS in account [0,1]. The user need 
only type the RETURN key, after which the second query line is printed. 
The second query line requests a device designator for the output medium, 
which, for example purposes, is the line printer (LP:) in the 
sample dialogue . Upon completion of the output, program execution 
is automatically terminated and READY is printed at the keyboard 
printer . 

It is useful for the system manager to cause the ANALYS system 
program to run automatically. This automatic invocation of ANALYS 
is accomplished by placing the proper commands in the CRASH. CTL 
file as FORCE directives. As a consequence of a system crash, the 
INIT system program, executing the FORCE directives in the CRASH. CTL 
file, causes a job to be logged into the system, ANALYS to be run, 
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and the job to be logged off the system. The method of accomplishing 
the automatic invocation of ANALYS is described in Section 5.1.2. 

The output of an ANALYS system program run supplies valuable 
hardware and software information which can be used by a' software 
specialist to determine possible causes of system crashes. 

5.9 PROCESSING USER COMMENTS - GRIPE 

The RSTS-11 system provides a program to allow users of the 
system to communicate comments to the system manager. Comments are 
entered, under the control of the GRIPE system program, to a common 
file named GRIPE.TXT. The GRIPE system program is optional on the 
RSTS-11 system and must be stored in its compiled form in the system 
library account [1,2] with a protection of <168>. The file, 
GRIPE.TXT, which retains the user comments for inspection by the 
system manager, is created, expanded, and deleted on an as-needed 
basis under the system library account [1,2]. As an aid in 
identifying the user who entered the comment, the GRIPE system program 
uses an expanded name supplied in the individual user's account 
information in the ACCT.SYS file, also stored in the system library 
account [1,2]. However, the expanded name and entry in the ACCT.SYS 
are not required for GRIPE to run. 

5.9.1 User Input Via GRIPE 

The user enters comments to a common file for examination by 
the system manager with the GRIPE system -program. GRIPE is invoked 
by the following command: 

RUN $GRIPE 

GRIPE indicates that it is ready to accept user comments by printing 
a query line as follows : 

YES? (END WITH ESCAPE ) 

The user is then allowed to type the text of his comment which 
is entered into the common file. The user terminates the text of his 
comment by typing the ESC or ALT MODE key. (Typing ESCAPE or ALT 
MODE key is echoed at the keyboard printer by a dollar sign 
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character ($) being printed.) No carriage return-line feed operation 
is performed. The program indicates its acceptance of the text and 
its termination by printing the following lines. 

THANK YOU 
READY 

5.9.2 Privileged Feature of GRIPE 

The system manager or a privileged user invokes the GRIPE 
system program in the same manner as the general user. Once GRIPE 
prints its query line , the system manager can then examine the con- 
tents of GRIPE.TXT or can clear the contents of GRIPE.TXT. 

The *LIST command is used in the following manner to examine the 
contents of the GRIPE.TXT file. 

RUN &GRIPE 

YES? (END WITH ESCAPE ) 

*LIST$ OUTPUT? LP: 

READY 

The system manager types *LIST and the ESCAPE or ALT MODE key 
immediately after the query line. (Typing the ESCAPE or ALT MODE key- 
on a separate line causes *LIST to be entered as text into the 
GRIPE.TXT file.) If the GRIPE.TXT file is empty, the message NO 
GRIPES FOUND is printed, followed by the READY message. Otherwise, 
the GRIPE program requests an output device on which to list the 
contents of the GRIPE.TXT file by printing the OUTPUT? query. The 
system manager can type the RETURN key to have the comments listed 
at the keyboard printer or can type a device designator, such as 
LP: shown in the example above. The output for each user comment in 
the GRIPE.TXT file consists of an identification line (including the 
account entering the comment, the date and time it was entered, and 
an account name taken from the ACCT.SYS file) and the text of the 
comment. The program run is automatically terminated upon completion 
of the output. Control is returned to BASIC-PLUS. This action is 
signalled by printing of the READY message. 

The system manager clears the contents of the GRIPE.TXT file 

by using the *RESET command after invoking GRIPE. The following 
example demonstrates the use of *RESET. 
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RUN $ GRIPE 

YES? (END WITH ESCAPE) 

*RESET$ 

READY 

The system manager must type *KESET immediately followed by the 
ESCAPE or ALT MODE key. The clearing of the GRIPE.TXT file and termi- 
nation of the GRIPE run is signalled by the READY message. 
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5.10 MANAGING RSTS ERROR LOGGING - ERRCPY, ERRCRS AND ERRDIS 

Logging of hardware errors is an automatic function of the RSTS 
monitor. To gain the advantages of error logging, the system manager 
must properly employ the ERRCPY, ERRCRS, and ERRDIS system programs. 

The ERRCPY program retrieves error-related data logged by the 
RSTS monitor. Upon occurrence of a hardware error, special routines 
save the contents of the device registers in memory and transfer the 
saved data to disk. 

The ERRCRS program retrieves error-related data saved following 
a system crash. When a system crash occurs and certain conditions 
are in effect, the monitor preserves the contents of certain critical 
parts of the system. The system file CRASH. SYS holds this information 
along with other error-related device data. The ERRCRS program 
transfers the information from the CRASH. SYS file to another disk file 
which has the same format as the one created by the ERRCPY program. 

The ERRDIS system program produces summaries of error-related 
data and formats it for output to a hard copy device. This program 
provides the record of errors logged on the RSTS system. 

5.10.1 Operation and Use of the Error Copy Program - ERRCPY 

The error copy system program ERRCPY reads error-related informa- 
tion stored in the monitor part of memory and writes it to a special 
disk file. The system manager must ensure that the proper commands 
are created in the START. CTL and CRASH. CTL files as described in 
Section 5.1 so that ERRCPY is started and active during time sharing 
operations. The following discussion outlines the entire process 
of activating the job which runs ERRCPY. 

When the RSTS system starts up, commands in either the START. CTL 
or CRASH. CTL control file are executed by the INIT system program. 
If the command FORCE KB0: RUN $ERRCPY appears in the control file, the 
command RUN $ERRCPY is placed in the input buffer of the console 
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terminal (KBJ2f:) as if it- had been typed at the terminal. Meanwhile, 
the accompanying END command in the control file causes termination 
of the INIT system program and causes the console terminal to be 
placed at BASIC-PLUS command level (edit mode) , as signalled by the 
READY message being printed. The console terminal remains logged into 
the system under account [1,2] . 

When the system executes the command RUN $ERRCPY from the input 
buffer of KBJ2f: , the ERRCPY program runs and detaches itself from the 
console terminal as indicated by the message DETACHING printed at the 
console terminal. The console terminal is not thereafter logged into 
the system, but ERRCPY continues running as a detached job under 
account [1,2] . 

When ERRCPY is activated, it exists in the SL (sleep) state and 
neither occupies memory storage nor uses CPU time until awakened by 
the RSTS Monitor error logging routines. When error iogging detects 
a hardware error, it causes ERRCPY to run and write the error-related 
information to a special file ERRLOG.FIL. The file is stored under 
the system library account [1,2] on the system disk. If ERRCPY is not 
running, the diagnostic area is overwritten and the history of sub- 
sequent errors can be lost. Therefore, the system manager must 
properly start the ERRCPY job. 

The system manager gains information concerning the hardware 
errors detected and placed in the ERRLOG.FIL by running the ERRDIS 
system program as described in Section 5.10.3. If a system crash 
occurs, the system manager can retain error data by following the 
instructions in Section 5.10.2. 

5.10.2 Retaining Error Crash Information - ERRCRS 

The ERRCRS system program saves error information retrieved at 
the time of a system crash. When system crash occurs, critical contents 
of memory are written to the system file CRASH. SYS if the user enabled 
the CRASH DUMP facility at start up time. The ERRCRS system program 
transfers certain error information from the file CRASH. SYS to a user 
designated file. The following sample dialog shows the use of ERRCRS. 
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RUN $ERRCRS 

ERRORS V05-06 

OUTPUT FILE NAME? FILE.CRS 

CRASH DUMP FILE NAME? 

READY 

ERRCRS is executed by typing the RUN $ERRCRS command from a terminal 
logged into the system under a privileged account. Two queries are 
printed. The response to the first query designates the name of a 
file to which error information will be written. The response to 
the second query is simply the RETURN key, designating the file 
CRASH. SYS stored under the system account [0,1]. The ERRORS program 
writes the error information to the file named FILE.CRS (in this sample) 
and terminates automatically, as signalled by the READY message being 
printed. 

The system manager can later print a report on the error informa- 
tion saved if he uses the ERRDIS system program as described in 
Section 5.10.3 and designates the filename specified as output of 
the ERRCRS program run as the input filename for ERRDIS. It is 
highly recommended that the system manager place the proper commands 
in the CRASH. CTL file so that ERRCRS runs automatically upon 
initialization of the system after a system crash. 

5.10.3 Operation and Use of the Error Display Program - ERRDIS 

The error display program ERRDIS allows the system manager to 
gain full or partial history or a full or partial summary of the error- 
related information preserved by the ERRCPY or ERRCRS system programs. 
ERRDIS prints, in an organized and formatted fashion, the error-related 
information read from a disk file according to options and switches 
specified by the system manager. The file is created by either the 
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account [1,2] with protection code <60>. The disk file can maintain 
a history of a maximum of 880 errors and can record a maximum of 100 
of any one type of error. If either of these limits is reached, ERRDIS 
prints in the output history a message telling how many errors were 
missed due to no room or to the limit of 100. The following two 
sections describe how to run and terminate ERRDIS and how to optimally 
use ERRDIS features. 
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5.10.3.1 Running and Terminating ERRDIS - The system manager or 
privileged user runs the ERRDIS program by typing the following command 
while logged into the RSTS system. 

RUN $ERRDIS 

The program responds by printing a program header line, followed, in 
turn, on subsequent lines, by three queries as shown below. 

ERRDIS V05-10 

INPUT FILE NAME (<CR> FOR DEFAULT)? 

OUTPUT TO? 

OPTIONS? 



The user types the RETURN key in response to the query concerning the 
input file name and ERRDIS prints the second query concerning the 
output device or file. The default input file name is $ERRLOG.FIL. 
The user can specify as input the name of the file created by the 
ERRCRS program. If the user types the RETURN key in response to the 
second query, the error-related information subsequently requested 
is printed at his terminal keyboard printer. To indicate a different 
output device, or file, type the proper specification followed by 
the RETURN key. 

After the user designates the output, ERRDIS prints the OPTIONS 
query. An option from those given in Table 5-9 can be typed. An 
option can be modified by any of several switches as described in 
Table 5-10. After output of the option or options specified is 
completed, the OPTIONS query is printed again. To terminate the 
ERRDIS program, type the EXIT command in response to the OPTIONS 
query. 

OPTIONS? EXIT 
READY 

Control is returned to BASIC-PLUS command level, as indicated by 
the READY message being printed. 
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Table 5-9 
ERRDIS Program Options 



Option 
Type 


Option 

Format 


Meaning 


General 


ALL 


Error-related information for all errors 
is printed in the order in which they were 
detected and recorded, from the earliest 
to the most recent. 




EX 


Terminate ERRDIS and exit to the monitor. 




HE 


Print the help file ERRDIS. HLP. 




MS 


Missed errors. 


Peripheral 
Errors 


DT 


TC11/TU56 DECtape 




RF 


RF11/RS11 fixed head disk 




RC 


RC11/RS64 fixed head disk 




RK 


RK11/RK05 or RK03 DECpack cartridge drive 




CD 


Card reader 




MT 


TM11/TU10 Magtape 




KB 


Hung Teletype errors by job number and 
keyboard line number. 


Processor 

Errors 


T4 


Traps through vector location 4 




10 


Traps through location 000000 




Tflf 
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RI 


Reserved instruction traps 




PF 


Occurrences of power failure 


i 


CK 

1 


Checksum errors 

i 
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Table 5-10 
ERRDIS Program Option Switches 



Switch 
Format 



/S 

/K 

/H 
/dd-mmm-yy 

/hh:mm 



Meaning 



Print only a summary of information of the error type 
indicated in the option. (Used alone, /S is meaning- 
less.) 

Delete (kill) the information from the ERRLOG.FIL file 
and exit to READY. 

Used alone; causes a help file to be printed. 

Prints information concerning the error type indicated 
in the option if it was detected on or after the date 
designated by /dd-mmm-yy. For example, 19-MAY-73. 

Prints information concerning the error type indicated 
in the option if it was detected at or after the time 
of day designated by /hh:mm. ' For example, 8:50 or 
20:50. 

If a date switch appears with a time switch, ERRDIS 
prints errors detected at or after the date and time of 
day. If a time switch appears without a date switch, 
ERRDIS uses the current system date. 



5.10.3.2 Recommended Usage of ERRDIS - The recommended procedure 
for using the ERRDIS program is to daily request at least two specific 
options: ALL/S and ALL. The procedure entails running ERRDIS and 
answering the OPTIONS query in the following manner. 

OPTIONS? ALL/S 
OPTIONS? ALL 

The ERRDIS program first creates a summary (/S) of all error- 
related information. The output starts with 4 lines of accounting 
data. On the first line, ERRDIS indicates the option requested, 
followed, on a second line, by the file name from which the information 
is taken (usually $ERRLOG.FIL) . On the third line appears the output 
specification used and, on the fourth line, the time of day and current 
date. Following the accounting data is the summary of the total number 
of errors missed by type. 



5-45 



February 1975 



For the second option requested (ALL) , ERRDIS prints the account- 
ing data and the entire history of the errors logged. Information 
for each occurrence of a logged error is printed in chronological 
order, beginning with the earliest error and continuing to the most 
recent occurrence. For each error logged, a header line is printed 
which describes the type of error and the time of day and date of the 
occurrence. Following the header line for each error, ERRDIS prints 
such data as job number, keyboard number (if a hung Teletype error) , 
processor status word (PSW) contents, and the contents (in octal) of 
the device registers at the time of the error. Consult the PDP-11 
Peripherals Handbook for the meaning of the device register abbre- 
viations and the types of errors encountered. (A job number of 
indicates the null job.) A comment line is appended to some error- 
related information, such as that of a hung Teletype. 

At the conclusion of the error history, ERRDIS prints the number 
of missed errors (if any) and the total number of errors listed of 
those logged since the beginning of the error history. It is 
recommended that the user specify a disk file to contain the output 
of the options. The printouts of the complete summary and the complete 
history should be inspected and stored in a central location reserved 
for them. They provide the basis for planning preventive maintenance 
and the means to more readily isolate potentially dangerous hardware 
problems. The printouts should be available to the DIGITAL Field 
Service or Software Support representative. Periodically, the 
system manager can delete the contents of the file $ERRLOG.FIL by 
specifying the following option in response to the ERRDIS program 
OPTION query. 

OPTION? /K 

RRfllTV 



The system manager should be alert for certain conditions 
reported by ERRDIS. Several hung Teletypes are not serious, but a 
steadily increasing number of hung Teletypes on a certain keyboard 
line indicates a possibly dangerous condition which should be remedied. 
Any occurrence of a TJ& error is serious and indicates that an inter- 
rupting device has presented an incorrect vector location to the bus. 
An increasing number of disk errors (particularly on the system disk) 
indicates a need for immediate maintenance. 
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5.11 SETTING JOB PRIORITY AND TIME QUANTUM FACTORS - PRIOR 

The PRIOR system program reports the priority and time quantum 
factors assigned to an existing job. The system manager can change 
any of the current values to increase or decrease the chance of 
gaining run time in relation to other running jobs or to determine 
how much CPU time the job can have when it is compute bound. The pro- 
gram sets the values by using the -13 FIP call described in Section 
4.3.2. 

The system runs jobs on the basis of priority. The higher a 
job's priority, the better are its chances of obtaining run time in 
relation to other running jobs. Priority is determined by an 8-bit 
priority byte. By running PRIOR, a privileged user can set the 
priority for his own job or for another job on the system. Standard 
priorities are between -128 (lowest priority) and +127 (highest 
priority) . Zero is a legal priority. 

When a user first logs in on a system, LOGIN runs with priority 
0. LOGIN automatically sets the user's job to priority -1. This is 
the default priority with which most or all of the jobs are run. Only 
in unusual circumstances should priorities other than -1 be assigned. 

On occasion, the user may want to run a non-urgent program that 
requires a great deal of computation. If time is not a factor in 
obtaining results, the privileged user can decrease the job priority 
to improve efficiency for the other users on the system. Conversely, 
infrequently used detached programs often have higher priorities 
(typically priority 0) since they can be run quickly once, and ignored 
thereafter. 

The time quantum factors determine the maximum time a job can run 
compute bound before another job obtains access to the CPU. Each unit 
of time is equal to l/60th or 1/5 0th of a second, depending on the 
system's power line frequency. If the system is operating from a 
60 Hz power line, one unit equals l/60th of a second and six units 
equal l/10th of a second. 
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not require that much compute bound time, the system automatically 
transfers control to the next user before the six units have been used. 
One tenth of a second is generally considered the best time quantum 
to insure efficient overall system operation. If a job is guaranteed 
to become I/O bound (that is, I/O stalled) after a certain amount of 
computations, PRIOR can be used to specify a time quantum larger than 
6. In many cases, a time quantum of 8 units has a significant effect 
on long computational programs . 

5.11.1 Running PRIOR 

PRIOR is called as follows. 

RUN $PRIOR 

PRIOR V4B-01 PRIORITY AND QUANTUM CHANGER 

The first query line printed is: 

SPECIFY ANOTHER JOB NUMBER? 

If the current job is to be checked, type the CR key alone. 
If, however, the job to be checked is not the one under which PRIOR 
is running, type the job number to be considered. A job number less 
than 1 or greater than the maximum number of assignable jobs returns 
the error message ILLEGAL JOB NUMBER ENTERED. Only active, running 

error message. 

PRIOR now prints the current priority and time quantum for the 
job. For example: 

CURRENT STATISTICS FOR JOB 1: 

PRIORITY -1 

ADDITIVE QUANTUM FACTOR 4 
MULTIPLICATIVE FACTOR 1 

ANY CHANGES? 

If any or all of this information is to be changed, type Y in 
response to the ANY CHANGES query. Typing N or the CR key alone 
automatically ends the program. 
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If the user indicates that changes are to be made by typing Y 
in response to the ANY CHANGES query, PRIOR prints a query line for 
each parameter in turn- If the value assigned to any parameter is 
not to be changed, type N or the CR key alone to skip to the next 
query line. When the typed response to the query line is Y, the 
message CHANGE IT TO? is printed. Type the new specification as 
shown below in the sample dialog. 

ANY CHANGES? Y 

CHANGE PRIORITY? Y 
CHANGE IT TO? 
CHANGE ADDITIVE FACTOR? Y 
CHANGE IT TO? 6 

CHANGE MULTIPLICATIVE FACTOR? N 
CURRENT STATISTICS FOR JOB 1 : 

PRIORITY 

ADDITIVE QUANTUM FACTOR "5" 
MULTIPLICATIVE FACTOR 1 

ANY CHANGES? N 

READY 



Once the last query line has been answered, PRIOR prints the 
new statistics for verification and prints the message: 

ANY CHANGES? 

Typing Y allows the user to make additional changes to this 
information. Typing N or the CR key alone ends the program. 
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CHAPTER 6 



STAND-ALONE PROGRAMS 



This chapter contains the descriptions of two stand-alone pro- 
grams supplied in the RSTS-11 System. The programs are ROLLIN and 
DSKINT. ROLLIN program transfers data between DECtape . or Magtape and 
disk devices. The DSKINT program initializes and formats disk stor- 
age for use on the RSTS-11 system. 

Stand-alone programs are run by using the start-up procedures 
for RSTS-11 and by answering L as the start-up option. Respond to 
the query LOAD PROGRAM with the name of the stand-alone program — 
ROLLIN or DSKINT. (See Chapter 3 for details on starting RSTS-11.) 

6.1 INTRODUCTION TO ROLLIN 

ROLLIN is a stand-alone program used to transfer data quickly 
between a disk and either DECtape or magtape or between RKll disk 
cartridges. Disks handled by ROLLIN are the RF11, RC11, RPJ22, and 
RKll. ROLLIN assumes no file structure on disk or DECtape; trans- 
fers are performed in image mode. Magtapes are treated as file- 
structured devices in that each ROLLIN file is preceded by a DOS- 
compatible file label (see paragraph 6.1.4). 

When transferring data onto DECtape or magtape, ROLLIN auto- 
matically writes an initial record containing a tape sequence number 
called a reel label. For DECtape transfers, the reel label also 
contains the number of blocks of data transferred. The reel label 
guards against mounting tapes out of sequence when returning data 
to a disk device. 

Preceding all data records on a DECtape or the first file on 
a magtape, ROLLIN copies a core image of itself. This image permits 
ROLLIN to be bootstrapped off DECtape or magtape to load the remain- 
der of the tape. 

6.1.1 Command Format 

ROLLIN prints a # character on the teleprinter (or console 
teleprinter for a multiple terminal system) whenever it is ready 
to accept a command. ROLLIN commands are of the form: 
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#_devl : <dev2 : /options 

or, more simply: 

#/options 

where: devl: is the output device specification 
dev2: is the input device specification 
/options indicates one or more legal switch options 

The # character is underlined in examples to indicate that it is 
printed by ROLLIN rather than typed by the operator. 

Legal device specifications are as follows: 

Device Specification Device 

DF: RF11 disk (256K unit) 

DC: RC11 disk (64K unit) 

DKn: RKll disk, units to 7 (1.2 

(n = to 7) million words/cartridge) 

DPn: RP02 disk, units 0-1 (10 million 

words per disk pack) 

DTn: DECtape, units to 7 (each reel 

(n = to 7) contains 578 blocks, each 256 

words long) 

MTn:name Magtape, units to 7 

(n = to 7) (A filename must be specified. 

It is written in the file label 
and must not include a filename 
extension) 

The digit should not be omitted from the specification Wnen 
a unit is indicated. For example, DK: is illegal. 

An example of a ROLLIN command is shown below: 

#MTj2> : DAT8>DC : 

The above command dumps the entire contents of an RC11 disk onto 
a magtape file called DAT8 on the magtape reel mounted on magtape 

nn T 4- Hi 
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TABLE 6-1 



ROLLIN Option Switch Descriptions 



Option 
Switch 



Abbreviation 



Meaning 



/BOOT : dev 



/BO:dev 



/DATE : date 



/DA: date 



/FIND 



/FI 



/HELP 
/NOLABEL 



/HE 
/NO 



This general-purpose bootstrap 
switch, which loads the first 
256 words of core from the de- 
vice and then branches to loca- 
tion 0, is used to bootstrap DOS 
or RSTS; for example: 

#/B0 : DK 

loads and starts an RKll DOS 
system. 

Used in writing the FILE LABEL 
on magtape. /DA causes the 
specified date to be entered in 
the FILE LABEL. The format for 
the date is day-month-year; for 
example: 

#/DATE:l-FEB-72 

Used with magtape only. When 
reading from magtape, /FI re- 
winds the tape and searches for 
the specified file. When dumping 
to magtape, /FT causes the tape 
to skip past all the files pre- 
viously written on the tape. 

Types a brief explanation of 
ROLLIN options on the console. 

On dumping disk to DECtape,, this 
option inhibits the reel label 
record from being written . 



/NUMBER: n 



/NU:n 



/PLATTERS : n /PL : n 



n is the number of IK disk tracks 
to dump or restore. If /NUMBER 
is not specified, the entire disk 
is used. 

For use with RF11 or RC11 disks 
only, n is the number of disk 
platters to load or dump . /PLATTERS : 1 
is always assumed if not specified. 



/RSTS 



/RS 



This special-purpose bootstrap 
switch is used to bootstrap RSTS 

from the RFll disk. 
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TABLE 6-1 (Cont. 



ROLLIN Option Switch Descriptions 



Option 
Switch 



Abbreviation 



Meaning 



/RWIND 



/RW 



When reading or writing magtape, this 
switch causes the tape to be rewound 
before use. 



/SKIP:n 



/SK:n 



When reading or writing magtape, 
this switch causes the tape to 
skip past n end-of-file marks 
before starting a read or write. 



/V4A 



/V4 



Obsolete option. 



6.1.2 Editing Commands to ROLLIN 

Editing procedures for ROLLIN command strings are identical to 
those for DOS and RSTS command strings. 

While typing a command line, the operator can use the RUBOUT 
key repeatedly to delete preceding characters. The entire command 
line can be deleted by typing CTRL/U. 

When ROLLIN is printing on the the teleprinter, typing CTRL/0 
inhibits further printing. 

6.1.3 Disk/DECtape Operations 

DECtape is a block-structured device. DECtape reels contain 
57 8 blocks, each 256 words in length. When ROLLIN writes a DECtape, 
it dumps its own image onto blocks to 12, writes a label onto 
block 15, then dumps data from the disk onto blocks 16 through 527. 
This means that 12 8K of data can be kept on each tape. Hence, an 
RF11 disk requires two DECtapes , while an RK03 disk requires ten 
DECtapes for a complete dump. 

When a disk is restored from DECtape, ROLLIN checks the label 

WnrV on osrh reel to ensure that. t.hp. tanes are used in the proper 
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sequence, and that the number of blocks restored does not exceed 
the number of blocks dumped. If this is not the case, an error 
message is printed. 

6.1.3.1 Disk to DECtape Dump 

To dump disk to DECtape, simply type DT : as the output device 
and the disk name as the input device. For example: 

#DT:<DK0: 

would dump RK03 disk cartridge onto ten DECtapes (unit would 
be used first, then units 1, 2, 3, 4, 5, 6, and 7, the ninth tape 
would then go back to unit and the tenth to unit 1) . This is 
the normal order for using tapes; the user could override this 
by typing the actual units to use. For example: 

#DT2: ,DT0: <DF: 

would dump the RF11 disk onto two tapes, using unit 2 first, and 
then unit 0. 

The use of the /NOLABEL option requires a brief explanation. 
This would only be used when writing over the first part of a DEC- 
tape previously written by ROLLIN. For example, suppose we have 
just patched the RSTS Monitor. This Monitor normally resides on 
the first 2 8K of the RF11 disk. Now suppose we want to dump this 
patched Monitor onto the first 2 8K of an earlier disk dump. This 
can be done by mounting the first dump tape on unit 0, loading 
ROLLIN, and typing the following command: 

#DT0 : <DF : /NUMBER: 2 8/NOLABEL 

This will write out the first 28K of the disk without rewriting the 
DECtape label. Now, when we restore from this tape, ROLLIN will 
read the entire tape, and not just the first 28K. 

6.1.3.2 Restoring Disk from DECtape 

This is simply the reverse of the dump operation and takes a 
similar command. For example: 
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£DF : <DT i 

would restore the RF11 from two reels of DECtape on units J? and 1. 

As before, reel numbers can be given explicitly, if desired; 
for example: 

#DF:<DT1: ,DT2: ,DT3: ,DT4 : /PLATTERS : 2 

would load a 2-platter RF11 disk (512K) from four DECtapes, mounted 
on units 1, 2, 3, and 4. 

6.1.4 Disk/Magtape Operations 

Magtapes are written by ROLLIN with 800 BPI density and odd 
parity. On 9-channel drives each 16-bit word takes two frames of 
tape. On 7-channel drives core-dump mode is used, so each 16-bit 
word takes four frames of tape. 

Each dump operation writes one file on the tape. This file 
normally consists of a 7-word file label record containing the 
filename (always with the .ROL extension), UIC (always [1,1]), 
protection code (always 155) , and date. This is followed by a 256- 
word reel label record that contains the reel sequence number for 
this file. Following this are the actual data records. Each data 
record, except possibly for the final one, contains 4K words (8K 
bytes) of data, ROLLIN closes the file by writing three end-of-file 
(EOF) records, one to end the file and two more to indicate the 
end-of-data (EOD) on the magtape. ROLLIN then backspaces over two 
of the EOF records to leave the tape correctly positioned for per- 
forming another dump. There is one exception to this file format. 
If, before writing the file label, the tape is positioned at the 
load point (beginning-of-tape) , two records are written immediately 
following the file label. These two records contain a bootstrap 
and an image of ROLLIN, and they are used in conjunction with the 
routine to load ROLLIN off magtape. 

The file label is DOS compatible, permitting mixing of ROLLIN 
files and DOS files on a single tape and cataloging of the tape via 
the /DI option of DOS PIP. However, DOS records are required to 

be 256 words in length, while ROLLIN makes more efficient use of 
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the tape by writing 4K words in each record. This means that ROLLIN 
files cannot be read in file structured mode by DOS (READ/WRITE) 
TRAN can, of course, be used with ROLLIN files (see the DOS Monitor, 
Programmer's Manual). 

Figure 6-1 illustrates the format of a tape with two files 
on it, the first of which is a dump of an RF11 disk, and the second 
a dump of an RK03 disk cartridge. 

6.1.4.1 Disk to Magtape Dumps 

To illustrate dumping from disk to magtape, suppose a system 
had one RF11 disk and two RK03 drives. These could be dumped as 
three files by the following commands: 

#MT0 : DFDMP<DF : /RWIND/DATE : 1-FEB- 72 
#MT0 : DK0DMP<DK0: /DATE : l-FEB-72 
#MT0 : DK1DMP<DK1 : /DATE : 1-FEB- 7 2 

The filename must be specified with magtape, the date is optional 
but should be specified. The magtape now has three files on it: DFDMP, 
DK0DMP, and DK1DMP. Note that the file extension is never speci- 
fied by the user; the extension will always be a .ROL. 

This assumes that a tape has been mounted, WRITE ENABLEd, on 
unit 0. To use another unit simply designate MT1:, MT2:, etc. in 
place of MT0: . 

A large 2400-foot reel can easily hold this much data; however, 
a small 600-foot reel would not have enough room for a complete 
dump of the second RK03. When ROLLIN detects the end-of-tape, it 
backspaces over the last data record, writes three end-of-file rec- 
ords, and prints the following message: 

TAPE FULL, TYPE M TO MOUNT ANOTHER REEL AND CONTINUE, 
ANYTHING ELSE TO ABORT REQUEST: 

If another tape is available, type M followed by the RETURN key. 
ROLLIN now prints the following message: 

TYPE RETURN TO CONTINUE WHEN READY. 



6-7 



LOAD 

POINT 



FILE LABEL 



ROLLIN BOOT 



ROLL IN 
IMAGE 



REEL LABEL 



4K DATA 
RECORD 



4K DATA 
RECORD 



EOF 



FILE LABEL 



REEL LABEL 



4K DATA 
RECORD 



EOF 



EOF 



EOF 



RF11 DUMP 



64 4K RECORDS 



RKll DUMP 



300 4K RECORDS 



Figure 6-1 ROLLIN Magtape Format 
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Now mount the new tape (it must be on the same unit number) . Type 
the RETURN key and ROLLIN will finish the dump. 

After a tape has been dumped it is recommended that the WRITE 
ENABLE ring be removed. 

6.1.4.2 Restoring Disk from Magtape 

Returning to our illustrative case, the three files could be 
restored from magtape by the following commands: 

#DF : <MT0 : DFDMP/FIND 
#DK0 : <MT0 : DK0DMP 
#DK1 : <MT0 : DK1DMP 

Here, the /FIND switch rewinds the tape and searches for the 
file DFDMP which would in this example be the first file on the 
tape. While /FIND may always be used, if you are certain that 
the tape is correctly positioned, omitting /FIND will greatly speed 
the restore process since no search for the file will made. ROLLIN 
will, in any case, verify that the filename is the same as the speci- 
fied name, and that the extension is .ROL, and give an error if it 
is not. 

This again assumes that the tape dumped by the commands given 
in Section 6.1.4.1 has been mounted on unit 0. If an end-of-file is 
encountered during the read, as would be the case with a 6 00- foot 
reel, then ROLLIN will ask for another reel by printing: 

END-OF-FILE DURING READ, TYPE 

M TO MOUNT ANOTHER REEL, OR K TO KILL REQUEST: 

If the second reel is available, respond M followed by the RETURN key. 
ROLLIN now prints the following message: 

TYPE. RETURN TO CONTINUE WHEN READY. 

Now dismount the current tape and mount the continuation tape (it 
must be on the same unit number, as before) . Type return and ROLLIN 
will finish the read. 
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6.1.5 Copying RK11 Cartridges 

One more option available with ROLLIN is to do a dump from one 
RK11 cartridge to another, In this case, a direct copy is done, 
with no header or labeling information being written. For example: 

#DKj?:<DKl: 

would copy the entire contents of the cartridge mounted in drive 1 
onto the cartridge mounted in drive 0. 

6.1.6 Error Messages 

Error messages promulgated by the ROLLIN program are succinct 
and require little interpretation by the operator. 

SYNTAX ERROR, COMMAND IGNORED. 

DISK ERROR, REQUEST KILLED. 

THE REEL LABEL INDICATES THAT THE REST OF THE TAPE WAS NOT 
DUMPED, TYPE K TO KILL REQUEST AT THIS POINT, ANYTHING ELSE 
TO PROCEED IN THE FACE OF DANGER: 

LABEL INDICATES THAT THE TAPE IS OUT OF SEQUENCE. TYPE P 
TO PROCEED, M TO MOUNT ANOTHER REEL, OR K TO KILL REQUEST. 

PREMATURE END-OF-FILE, REQUEST KILLED. 

TAPE FULL, TYPE M TO MOUNT ANOTHER REEL AND CONTINUE. 
ANYTHING ELSE TO ABORT REQUEST: 

MAGTAPE SELECT- ERROR. 



FATAL MAGTAPE ERROR. 

SPECIFIED DEVICE DOES NOT EXIST'. 

REACHED END-OF-DATA ON SKIP, OPERATION KILLED. 

HUNG DEVICE DTn 

TYPE K TO ABORT, ANYTHING. ELSE TO TRY AGAIN: 

MOUNT TAPE ON DECTAPE n 

TYPE RETURN TO CONTINUE WHEN READY. 

TOO FEW DECTAPE UNITS WERE SPECIFIED. REQUEST KILLED. 
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6.2 INTRODUCTION TO DSKINT 

DSKINT is a stand-alone program used to format RK11 or RP02 
disks and to build RSTS-11 structures on RKll, RP02 , or RF11 disks. 
The structures built by the DSKINT program are the MFD, the [0,1] 
UFD, the Monitor files SATT.SYS and BADB.SYS and a dummy bootstrap 
routine. The format and building operations permit the initiali- 
zation of RSTS-11 private disk, public non-system disks and enables 
bad block checking of all RSTS-11 disks. 

6.2.1 Running DSKINT 

To run DSKINT, follow the starting procedures of Section 3.2. 
Request the LOAD option and proceed as described in Section 3.3.3. 

When DSKINT is loaded, the RSTS-11 Monitor is overlayed and destroyed. 
Therefore, the program re-initializes itself after completion of each 

run. 

The user is informed that DSKINT is ready to run by the 
following header and query lines printed at the console: 

RSTS DISK INITIALIZER V4A-00 
DISK(RF,RK,RP) = 

The user supplies the proper choice of disk types from one of those 
shown. RSTS-11 does not check if the device is legal for the system. 
It checks for the proper two characters only. 

If any typing errors are made, typing the RUBOUT key echoes 
back the last character typed and removes it from the line buffer. 
If RUBOUT is typed once for each character entered, the line buffer 
is emptied and further occurrences of RUBOUT are ignored. Typing 
CTRL/U allows retyping of the current line. Typing CTRL/C restarts 
the DSKINT program. LINE FEED and RETURN characters are inter- 
changeable. 

The dialogue continues at the console until the user is re- 
quested to ready the disk unit and type the RETURN key. If no 
errors are detected, the termination dialogue is signalled by the 
following lines being printed on the console: 

INITIALIZATION COMPLETE 

RSTS DISK INITIALIZER V04A-00 

DISK(RF,RK,RP) = 
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6.2.2 Terminating DSKINT 

The DSKINT program is terminated by rebooting the RSTS-11 
Monitor and following the start procedures described in Chapter 3. 

6.2.3 Errors in Dialogue Queries 

The DSKINT program detects invalid user entries during the 
dialogue, prints "BAD SPECIFICATION", retypes the question to 
which the invalid response was typed. This can happen in any of 
the following cases: 

1) DISK NOT EF, RK, OR RP 

2) DRIVE NUMBER GREATER THAN 7 

3) PACK CLUSTER NOT 1, 2, 4, 8, OR 16 

4) MFD CLUSTER NOT GREATER THAN OR EQUAL TO PACK 

CLUSTER OR NOT 1, 2, 4, 8, OR 16 

5) MFD OR PACK ID NOT ALPHANUMERIC 

6) PUB OR PRI NOT SPECIFIED 

6.2.4 Errors in Formatting Operations 

If the specified disk unit is WRITE PROTECTED or NOT READY 
the following line is typed: 

DISK NOT READY - RESTART 
The DSKINT dialogue is restarted. 

If, for any other reason, the disk cannot be formatted, a disk 
diagnostic is printed (with NA for "not applicable" replacing the 
sector number) followed by the message: 

FORMATTING FAILURE 

The DSKINT dialogue is restarted. (See Section 6.2.6 for disk diag- 
. nostics. ) 

If the disk has not been formatted and the user did not answer 
Y to the formatting question, a diagnostic is generated for each 
sector on the disk. If this occurrence is evident, the user should 
type CTRL/C to restart the dialogue rather than wait for a diagnos- 
tic to be printed for each sector on the disk.. 
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6.2.5 Errors in Initialization Operations 

If an error occurs during creation of the directories, the 
Monitor files, or the bootstrap routine; or if a hardware disk error 
cannot be cleared; a disk diagnostic is typed, followed by the mes- 
sage shown below: 

FAILURE - UNRECOVERABLE ERROR DURING FINAL INIT. 

The dialogue is restarted. (See Section 6.2.6 for disk diagnostics.) 

If the number of sectors which are found to be bad exceeds 256 
times the pack cluster size, the following message is typed: 

EXCESSIVE BAD SECTORS 

The user should not wait for all of the disk diagnostics to print at 
the terminal if it is clear that a diagnostic is being printed for 
each sector. For example, to generate an EXCESSIVE BAD SECTORS mes- 
sage for a pack cluster size of 1, 401 (octal) sector diagnostics are 
printed at the console. The printing time is over twenty minutes. 

If one of the sectors allocated to the directories, the Monitor 
files, or the bootstrap routine is found to be bad, the following 

message is typed: 

INIT FAILED - AT LEAST 1 CRITICAL SECTOR IS BAD 

The dialogue is restarted. 

6.2.6 Errors on the Disk 

Errors on the disk are reported by sector number (an octal 
value) and the related contents (octal) of selected hardware regis- 
ters, dependent upon the type of disk device. Upon the first occur- 
rence of a sector being determined to be unusable, a title line is 
printed; the title line contains mnemonics describing sector and 
which hardware values are placed in that column. Although some of 
the mnemonics appear different in spelling, the PDP-11 values have 
not changed. For example, RKMA is equivalent to RKBA, where M 
(memory) has replaced B (bus) in the bus address register. 
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6.2.7 Execution Times by Disk Type 

The following values are approximate times for formatting and 
initializing the various types of disks. The values should be used 
as a guideline only. 



Operations 


Device Type 




RF11 


RK11 


RP11 


Formatting 


Not allowed 


30 seconds 


1 min, 30 sees. 


Initialization 


1 minute 


7 minutes 


35 minutes 
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APPENDIX A 
SYSGEN INTERROGATION SUMMARY 



QUESTIONS 


RANGE OF ANSWER 


DEFAULT ASSUMPTION 
FOR NULL ANSWER 


Long or short form of 


S for short form. Any- 


Long form 


questioning? 


thing for long form. 




— 

System name? 


Up to 15 alphanumeric 
characters. 


(none) 


AC power frequency? 


60, 50 


60 


Line clock or program- 


L, P 


Line Clock 


mable clock? 






Power Fail code? 


Y, N 


Y 


Highest job number? 


1 through 17 


(none) 


Number of KLll inter- 


through 16 





faces? 






Number of DC11 inter- 


through 16 





faces? 






Number of DLllE inter- 


through 16 





faces? 






Terminal "fill" cap- 


Y, N 


N 


ability? 






Serial LA30? 


Y, N 


N 


Lower Case 


Y, N 


N 


Escape 


Y, N 


N 


XON/XOFF remote reader 


Y, N 


N 


control? 






Automatic DC11 answer- 


Y, N 


N 


ing? 






CRT terminals? 


Y, N 


N 


No parity (1) , even 


1, 2, 3 


No parity generation 


parity (2) , or odd 




(1) 


parity (3) for terminal 






output? 






Number of RF11 disk 


through 8 


1 


platters? 






Number of RK11 disk 


through 8 





drives 
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QUESTIONS 



Swap only RF 

Number of RC11 disk 
platters? 

High speed reader? 

High speed punch? 

Number of dual DEC- 
tape drives? 

Number of big buffers 



Card reader? 

Card reader decode 
table: 029, 026, or 
1401? 

Line printer? 

LS11 type printer? 

Line printer vertical 
format software? 

Number of print-columns 
on line printer? 

96 character set on line 
printer? 

Number of MagTape 
drives? 

Number of Small Buffers? 

Math package? 

24-hour time 

Catastrophic error 
recovery? 

Record I/O 

Update? 

PRINT USING? 

Matrix verbs? 

Line printer assembly ' 
listings? 



RANGE OF ANSWER 



Y, N 




through 


4 


Y, N 




Y, N 




through 


4 


1 through 


8 


Y, N 




029, 026, 


1 


Y, N 




Y, N 




Y, N 





80, 132 

Y is 96; N is 64 

through 8 

10 through 999 

2 , 2E , 2X , 2EX 
4, 4E, 4X, 4EX 

Y, N 

Y, N 

Y, N 

Y, N 

Y, N 

Y, N 

Y, N 



DEFAULT ASSUMPTION 
FOR NULL ANSWER 



N 


N 
N 
1 



2 times the number 
of dual DECtape 
drives. 

N 

029 decode table 



N 
N 
N 



80 



N (upper case only) 



64 

(„, — ,~\ 

N 
N 

N 
N 
N 
N 
N 
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QUESTIONS 


RANGE OF ANSWER 


DEFAULT ASSUMPTION 
FOR NULL ANSWER. 


Media 


DT, MT, DK 


(none) 


DSKINT in CIL 


Y, N 


N 


ROLLIN in CIL 


Y, N 


N 
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APPENDIX B 
RSTS-11 TERMINAL SOFTWARE OPTIONS 

B.l ESCAPE, ALTMODE, PREFIX 

Some terminals have outmoded ASCII character keys: 

17 5 g = ALTMODE 

l76 g = PREFIX 

More recently designed terminals incorporate the 1968 ASCII character 
set, in which the following control characters appear: 

33„ = ESCAPE 

175 8 = } 

176 8 = ' 

RSTS-11 interprets 33 „ as a line terminator. On input, RSTS-11 

software will also automatically translate 175„ and 176 into 33 

boo 

and consequently treat them also as line terminators. Depending 
however, on the option chosen at system-generation time, the system 
program— TTYSET can be used to alter internal parameters for a given 
terminal so that 175 s and 176 8 are not translated but remain them- 
selves. 
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B.2 LOWER AND UPPER CASE CHARACTERS 

Some terminals can send and can print both lower-case and upper- 
case characters. Thus, when a lower-case character is sent, the 
terminal is capable of printing the echo in lower case so that the 
user has an accurate visual representation of his lower-case trans- 
mission. 

Other terminals (e.g., VT05) can send either lower-case 
or upper-case characters but can print only upper-case characters. 
Whenever they receive a lower-case character, they print the corre- 
sponding upper-case character. Consequently if a user sends a lower- 
case character, the echo is printed in upper case and the user has 
no clear visual indication that his transmission was indeed in lower 
case. 

Other terminals, (e.g. ASR33, KSR33) , can neither send nor 
receive lower-case characters. If they receive a lower-case character, 
they will print the corresponding upper-case character. 

To protect users of the second type of terminal from inadvert- 
ently sending lower-case characters into the system or into a data file, 
RSTS-11 software can be configured with the capability of automat- 
ically translating all input lower-case characters to their corre- 
sponding upper-case counterparts before processing them. When 
this capability has been configured into the system, TTYSET has the 
power of selectively enabling or disabling it for any specified 
terminal . 

B. 3 GENERALIZED FILL 

At system-generation time, the RSTS-11 system can be configured 
to have the generalized terminal fill feature. If this feature is 
not included in the configuration, no fill-characters are sent by 
the RSTS-11 system. If this feature is included in the configuration, 
RSTS-11 is capable of automatically sending a sequence of nulls (JZfg) 
as fill-characters after certain control characters. The transmission 
of these meaningless nulls allows the terminal sufficient time to 
complete the physical action initiated by the control character and to 
become synchronized or ready to receive and print the next meaningful 
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character. The control characters after which the null characters 
are sent and the base number of null characters which are sent after 
each is shown in the table below- 



' Control character to 
be followed by null(s) 


Base number of nulls 
which will follow 


<CR> (15 g ) 


1 


<TAB> (11J 


1 


<VT> (13g) 


4 


<FF> ( 14 g) 


9 



The actual number of null characters that are sent after a control 
character are the base number indicated in the table multiplied by 
a fill factor set by TTYSET. For example, if a user runs TTYSET and 
sets a fill factor of for his terminal, then no fill characters 
are issued after any control character. If, however, he sets the 
fill factor for his terminal to 2, then 2 nulls will be output after 
<CR> or <TAB>, 8 nulls after <VT>, and 18 nulls after <FF> . 

B.4 XON/XOFF REMOTE READER CONTROL . 

If a low-speed paper-tape reader on a remote terminal (connected 
to the system through datasets and communications lines) is to be 
used under RSTS-11, three requirements must be fulfilled: 

(1) the terminal must be equipped with the 
requisite hardware for XON/XOFF remote reader 
control, 

(2) the RSTS-11 software must be configured at 
system-generation time to include the XON/XOFF 
software for remote reader control, and 

(3) TTYSET must be used to enable the XON/XOFF code 
for the given terminal . 

For local terminals with or without low-speed readers or for 
remote terminals without low-speed readers, none of this is required. 
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B.5 OUTPUT PARITY BIT 

RSTS-11 software can be configured at system-generation time 
to add always an odd or an even parity bit to its output to terminal- 
devices , or it can be configured to omit always the parity bit . 

DEC-supplied terminals ignore parity bits and operate in 
the same fashion whether or not RSTS-11 sends them a parity bit. 
This may not be true of non-DEC terminals. 

B.6 AUTOMATIC ANSWERING FOR REMOTE TERMINALS 

RSTS-11 can be configured at system-generation time to include 
an automatic answering facility for remote terminals connected to 
the system through dataphone ports. When this feature is included 
in the software configuration, the following sequence of actions 
occur: 

(1) Remote user dials and rings at the RSTS-11 dataset port. 

(2) RSTS-11 sends its carrier to the remote user. 

(3) The remote dataset sends its carrier back to RSTS. 

(4) Upon reception of the remote terminal carrier, RSTS-11 
simulates an I<LF> as being received from the remote 
user. This will cause the system program LOGIN to run. 

(5) LOGIN will scan the user's input buffer and find the I. 
Upon detecting the I, LOGIN branches to an automatic, 
answering routine. This routine as it is found on the 
supplied LOGIN. BAS causes the same action to be taken 
as happens when HELLO is found in the input buffer. 
The system manager, however, may wish to alter the 
automatic answering routine in LOGIN to perform whatever 
task or send whatever message he wishes. 

When the automatic answering software is excluded from the configura- 
tion, steps (4) and (5) never occur. 
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APPENDIX C 
SYSLOD ERROR MESSAGES 



The system loader program SYSLOD transfers a linked core image 
library from one device to a disk as a contiguous core image library. 
The user runs SYSLOD from magtape or DECtape during the system genera- 
tion procedure. The user must consult this section for error messages 
and possible recovery procedure if errors. are generated during SYSLOD 
execution . 

Error messages issued by the SYSLOD program can be of two types: 
recoverable errors and non-recoverable errors. 

C.l RECOVERABLE ERRORS 



The following errors are diagnosed and printed by SYSLOD. Once 
the error message is printed, SYSLOD restarts by identifying itself 
again, and printing the # (input request) character at the keyboard. 
The user should retry the most recent command, making the indicated 
corrections. Error messages for recoverable errors are preceded by 
one of the following: 



CIL U.CV 

LICIL dev 



(dev represents the device mnemonic) 



depending upon whether an error has been detected in the CIL (output) 
or LICIL (input) side of the most recent command string. 

SYNTAX ERROR 



This message is printed if the command input line contains a 
syntax error . 
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TOO MANY SWITCHES 

SYSLOD does not accept switches on the input side of the command 
string. If too many switches are specified on the output side of the 
command string for SYSLOD to handle, it issues this message. 

UNKNOWN SWITCH 

If SYSLOD does not recognize the switch as a valid switch, it 
prints this message. 

SWITCH ERROR 

If a switch is used incorrectly, SYSLOD prints this message. 
Incorrect use of a switch implies specification of an argument when 
no argument is valid or the lack of an argument when one is required. 

SWITCH CONTEXT ERROR 

This message is issued when switches are specified incorrectly 
for their definitions. 

ERROR IN SWITCH ARGUMENT 

This message is issued when decimal argument for any switch is 
too large to be contained in 16 bits. 

NONEXISTENT DISK OR DISK NOT READY 

Either (1) the disk specified in a command string does not exist 

; ~ -i-i.~ zr.: ,.,., — o_^„„ r->i 4-u ~ j.:„v «... ■: « 4- ~ U-.-.4- A «-. ^ ^4- -^^ -* A* . 

Xll 1.11C UUllll.^Ul.aL.XUlIf \J±. \ *• J LliC l~l.LO.rt. CAlOUOf WUl. J- O HUl. 1.CUUJ ■ 

UNKNOWN DISK NAME SPECIFIED 

This message is issued when a disk name other than those listed 
below is specified in a command string. 

DP (DP0 through DF7) 
DK (DK0 through DK7) 
DP (DP0 through DP 7) 
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ERROR WHILE FORMATTING RK DISK 

This message is issued whenever an error is detected while format- 
ting an RK disk unit. 

A xxx 
■ READY 

This message is issued when a problem exists with a peripheral 
device not in the "ready" state. Check the device and the operating 
instructions to determine the cause of the error and correct the error. 
When the problem has been rectified, type YES and the CARRIAGE RETURN 
key to continue. 

C . 2 NON- RECOVERABLE ERRORS 

The SYSLOD program prints an error message at the keyboard device 
when a non-recoverable error is encountered during processing. These 
messages are listed below, along with the action to be taken (if any) . 

INPUT IS NOT A LICIL 

The first line of the input file is not in correct format for a 
LICIL. The most probable cause of this error is an attempt to trans- 
fer a load module (filnam.LDA) instead of the LICIL (filnam.LCL) . 

END OF FILE BEFORE CIL LINE READ 

This error message is issued when SYSLOD reaches end-of-f ile 
before detecting the CIL line.. If the CIL is being loaded from 
DECtape, magtape, or disk, it is likely that part of the file has 
been destroyed and must be rebuilt. 

BOOTSTRAP NOT IN BLOCK 

This message occurs in Replace mode only (neither the NS nor ZE 
switch has been specified) . In Replace mode, SYSLOD searches 
bootstrap parameters to find the CIL to be replaced. If the first 
block number of the CIL hooked to the bootstrap (location 176 of BOOT) 
is 0, then block is not a hooked bootstrap, and this message is issued. 
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BOOTSTRAP NOT HOOKED TO CIL; CANNOT REPLACE 

This message occurs in Replace mode only; (neither the NS nor ZE 
switch has been specified) . If the first block indicator of the boot- 
strap (location 176 of BOOT) is non-zero, it must be pointing to a 
CIL. If the first formatted binary line of the "hooked" file is not 
COMD section #3, then the file is not a CIL. 

BLOCK SIZE DISCREPANCY BETWEEN CILUS AND SYSLOD 

This error message is issued when the NS switch is used with 
SYSLOD. Exactly the same parameters must be specified for SYSLOD 
as were specified for CILUS. 

LICIL TOO BIG, NOT ENOUGH RESERVED BLOCKS 

This message occurs for either of two conditions: 

a) In Replace mode, the new LICIL is larger than the old. 

b) In any other mode, the number of reserved blocks (BL:nnnn) 
is not large enough for the CIL. 

1ST LINE NOT COMD SECTION #4 OR 1 



After reading the CIL line, SYSLOD begins to load the LICIL. The 
first formatted binary line after the CIL line must be COMD section 
#4 or COMD section #1. After each core image is loaded, SYSLOD is set 
to load a new core image. If the beginning of the new core image is 
not COMD section #4 or #1, this error message is issued. 

COMD SECTION #4 SEQUENCE ERROR 

This error message occurs if the LICIL is being loaded from 
paper tapes, and one or more tapes are out of order. 

INPUT ERROR 

After a READ, the status in the buffer header has indicated that 
one of the following errors occurred: 
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a) invalid line error 

b) checksum error 

c) character parity error or illegal binary format 

d) device parity error 

LOGICAL BLOCK SIZE ERROR 

This error message is issued when the logical block size specified 
for the NS switch is not an integral multiple of the physical block 
size for the disk. 

END OF DISK BEFORE CIL COMPLETE 

The last block number of the output disk has been written, but the 
CIL is not complete. 

ILLEGAL EMT CALL 

An EMT call was made that was not recognizable as a valid 
DOS/BATCH EMT. Notify your Software Support representative. 

FATAL ERROR RETRY 

A fatal error has aborted the current operation. It must be 
retried. 

MT DISASTER NXM or ILC - IRRECOVERABLE 

An irrecoverable I/O error has occurred while reading or writing 
magtape. 

IRRECOVERABLE MT PROBLEM 

A persistent error has occurred while reading magtape. 

LICIL FILE NOT FOUND 

The specified LICIL could not be found under UIC [1,1] or UIC 
[200,200]. 
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NO SPACE FOR CIL 

Not enough contiguous disk space is available to create the CIL. 
Either (1) too many files already exist on the disk, or (2) there are 
too many bad blocks on the disk. 

BLOCK OR BLOCK 1 BAD 

Either block or block 1 on the disk is bad; the system cannot be 
generated, as both these blocks are essential to the disk file structure. 

PACK IS TOO BAD 

The current disk pack cannot be used, as there are too many bad 
blocks (BADB.SYS is full) . 

ESSENTIAL DISK BLOCK HAD I/O ERROR 

A MFD, UFD, or bit map block could not be written without encounter- 
ing I/O errors. Note that these blocks are written after the veri- 
fication phase. 

C.3 NOTES 



If the default block size is not used, the block size must be 
an integral multiple of the default size for the disk. 

The COMD (COMmunication Directory) contains a code number that 
identifies the kind of information that follows. SYSLOD expects the 
first formatted binary line it receives on input to be identified as 
code #4 (indicating that it is a LICIL) . 

On occassion, certain hardware problems such as magtape and RK 
disk head alignment, UNIBUS time out traps, and disk controller errors 
cause SYSLOD to halt. The system manager should immediately contact 
a DIGITAL field service representative. 
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APPENDIX D 



SUMMARY OP DOS-11 ERROR MESSAGES 



Following is a complete summary of all error messages which can 
appear when using the DOS Monitor and system programs. 

D.l ACTION MESSAGES 



Error Additional 

Code Information 

A001 User Call Address 

A002 Device Name (RAD50) 

A003 Link Block Address 

A004 User Call Address 



A005 


PAUSE Number 


A006 


Irrelevant 


A007 


Call Address 


A010 






A043 



Disk Pack Block Number 



Meaning 

Disk Address Error 

Device not ready 

No device or illegal 
device or INIT 

DECtape error; command CO 
will retry the operation 

FORTRAN PAUSE 

Loading paper tape out of 
order on Pass 2 of Linker. 
Load specified module next. 

MAGtape opened file exists 

MAGtape read error during 

open 

This is the block that is 
bad 



D.2 INFORMATIONAL MESSAGES 



Error 


Additional 


Code 


Information 


1350 


STOP Number 


1351 


Err Max Cnt Reached 


1352 


Addr of Log. Device 


1353 


Class, error # 


1354 





1354 





Meaning 

FORTRAN STOP 

FORTRAN abnormal exit 

No FORTRAN logical device 

No logging device 

Disk was not zeroed 

Illegal response to 
CONFIRM: (the DK11 Disk 
cartridge was not zeroed) 
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D.3 FATAL MESSAGES 



Error 


Additional 


Code 


Information 


F000 


Request Address 


F001 


Request Address 


F002 


Request Address 


F003 


Request Address 


F005 


Request Address 



F006 Request Address 

F007 Request Address 
F010 Request Address 



Meaning 

Dataset not INITed 

Stack overflow 

Invalid call 

Invalid .TRAN function 

.RLSE error (no .CLOSE 
after .OPEN on file- 
structured device) 

Device full (new file 
cannot be .OPENed) 

No buffer space 

Illegal .READ/. WRITE 
(incorrect mode for device 



F011 Request Address 



F012 Request Address 



F014 Request Address 



F015 Request Address 






F017 Device (RAD50) 



F020 Irrelevant 



F021 Irrelevant 



F022 Irrelevant 



F023 Program Size 



correctly) 

Illegal open (unused code 
or type unsuitable for 
device) 

Invalid open (no program 
return provided for 
failure) 

Bit map failure (device 
error on trying to read 
bit map) 

DECtape error (nonexistent 
memory addressed or end- 
zone reached dummy 
transfer) 

DECtape search failure 
(block requested cannot 
be found) 

File structures device 
parity error 

Too many datasets using 
low-speed paper tape (a 
maximum of one for each 
direction is allowed) 

Program Loader read 
failure 

Program Loader format 
error (program is not in 
absolute load format) 

Program too large for 
core available 
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Error 
Code 



Additional 
Information 



Meaning 



F024 

F025 

F026 

F027 
F030 

F031 
F032 
F033 
F034 
F035 
F036 

F037 

F040 

F041 

F042 
F043 
F240 
F342 
F344 
F346 
F350 
F352 
F356 



Request Address 

Device 

Disk Control Status 
Register 

Status 

Error Class/Number 

Address of Logical Device 

Status (MT) 

Call Address 

Call Address 

Block Number 

Lowest slot used by Tasks 

Lowest slot used by Tasks 

Low address of Task Code 

Low Address of Stack 

Error Register 
Block Number 
Irrelevant 
Contents of PC 



Illegal file structures 
operation, e.g., Delete 
or Rename of an open file. 

Master Directory full 
(when attempting to add 
UIC) 

Disk transfer failure 
(hardware error or 
persistent parity failure) 

RK11 hardware failure 

FORTRAN system error 

End of file (FORTRAN). 

Magtape hardware failure 

Invalid special function 

Invalid conversion code 

Disk (DK) failure 

RSX Loader-no slot 
available 

RSX Loader-illegal slot 
specified 

RSX Loader-ABS Task does 
not fit 

RSX Loader-ABS Task, not 
enough room for Stack 

RP Hardware failure 

RP Failure 

No space for file allocate 

Error Trap 

Reserved instruction trap 

Trace trap 

Power Fail trap 

Trap Instruction trap 

Unexpected device interrupt 
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D.4 SYSTEM PROGRAM MESSAGES 



Error 


Additional 


Code 


Information 


S200 





S201 





S202 


Error Status Byte 


S203 






S204 







S205 







S206 







S207 


Error 


Status Byte 


S210 








S211 
S212 

S213 

S214 

S215 
S216 

S217 

S220 

S221 
S222 



Meaning 

Too many .CSECT directives 

Conditionals nested too 
deeply 

EOD or device error on 
.WRITE or .READ 

Illegal switch, or too 
many switches, or illegal 
switch value, or switch 
value not given 

Too many or too few output 
files 

Too many or too few input 
files 

Input file not specified 
in command string 

EOD or device on .TRAN 

Unrecognized symbol table 
entry 

An RLD references a global 
name which cannot be found 
in the symbol table 

An RLD contains a location 

counter modification 
command which is not last 

Object module does not 
start with a GSD 

The first entry in the 
module is not the module 
name 

An RLD references a section 
name which cannot be found 



references a nonexistent 
module name 

The TPA specification 
references a nonexistent 
section name 

An internal jump table 
index is out of range 

Unassigned 

Unassigned 
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Error Additional 

Code Information Meaning 

5223 No more room for CSI 

input buffer or Monitor's 
- file manager routine, or 
Monitor ' s Library search 
buffer 

5224 Unassigned 

5225 Program too large or top 

too low (program has been 
linked below zero in 
memory) 

5226 An open angle bracket, <, 

is present in a line other 
than the first 

5227 l:No Primary Output Illegal file combination; 
2: Sec In = Sec Out arguments 2-6 for Editor- 
3: Sec In = Pri Out type commands 

4:Pri In = Sec Out 

5: Pri In •= Sec In Pri = Primary File 

6:Pri Out = Sec Out Sec = Secondary File 

5230 Error Status Byte Error on .BLOCK I/O 

5231 Illegal command, file- 
structured device required 

5232 No more than one action 

switch permitted 

g233 Specified UIC not found 

in MFD 

5234 Null file name given where 

file name required 

5235 No files found in UFD 

5236 Operation applicable to 

DEC tape only 

5237 File not found during file 

recovery operation 

5240 No space for file allocate 

5241 MF° is full 

5242 Meaningless command; no 

action taken 

5243 No < in first line of 

command 

5244 Already past requested 

position 

5245 Object module not found, 

could be out of order 

5246 Illegal library format 
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Error 
Code 



Additional 
Information 



Meaning 



S247 

S250 

S251 
S252 

S253 
S254 



Listing requested, but 
unable to read output 
library from specified 
output device 

Core library symbol table 
not specified first or ' 
consecutively 

No files found for *request 

File name given when none 
allowed 

Linker error 

It is illegal to ZEro the 
system resident disk 



D.5 WARNING MESSAGES 



Error 


Additional 


Code 


Information 


W002 


RAD 50 NAME 


W043 


Block Number 


W300 





W301 





W302 





W303 





W304 





X305 





W306 





W307 





W310 





W311 





W312 





W313 





W314 





W315 





W316 





W317 





W320 






Meaning 

Device time out 

Transfer error while using 
ITRAN to zero the Disk 

Non-unique module name 

Byte relocation error 

Multiple definitions of 
global symbol 

Buffer overflow 

Macro too long 

Recursive macro not allowed 

Empty save buffer 

Search failure 

No room to UNSAVE 

End of data 

Line feed illegal 

Negative argument illegal 

No arguments allowed 

Illegal argument 

Illegal text string 

Illegal command 

Page buffer almost full 
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Error 
Code 



Additional 
Information 



Meaning 



W321 

W322 
W323 



W324 
W325 

W350 








Number of Failures 



Attempting to write to 
closed file 

Undefined Global Symbols 

Illegal size of named 
.CSECT, or illegal entry 
in named .CSECT, or Tasks' s 
named .CSECT size too 
large (RSX) 

Too many entries in Task's 
named .CSECT (RSX) 

Illegal Priority Specifi- 
cation in Real-Time 
Header (RSX) 

RSX-Power Fail 
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APPENDIX E 
RSTS INITIALIZATION ERROR MESSAGES 

If the initialization code detects an error, it prints a message 
of the form FATAL INITIALIZATION ERROR AT nnnnnn where nnnnnn is a 
relative relocatable address in the related module. The following 
addresses and related conditions describe the errors. 



003112 
004724 
004756 
004760 
004762 
005460 
006376 
006400 
006564 
007074 
007334 
007562 
010526 
011334 
012276 
012300 
014774 
015746 



NO USABLE USER SPACE 

ERROR DURING PIP OPERATION 

?OVER.SYS[0,1] 

?ERRM.SYS[0 3 1] 

?SWAP.SYS[0,1] 

?BUFF.SYS[0,1] 

MFD CREATE FAILURE 

ACCT [1,1] SEARCH FAILURE 

MISMATCHED CLUSTERS 

CANNOT FIND CREATED FILE 

FILE NOT FOUND FOR SHIFTING 

CANNOT FIND FILE FOR DUMP 

FILE NOT FOUND IN 'OLD' OF REFRESH 

?BADB.SYS[0 3 1] 

SMALL BUFFER POOL FULL 

ERROR RETURN FROM FILE PROCESSOR 

BAD LISTHT FOR FILE 

UNRECOGNIZED SYSTEM DISK 
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APPENDIX F 
RSTS-11 AUTO-RECOVERY AND AUTO-RESTART FLOWCHART 



Error traps through vectors 
4 or 10 when system has been 
configured with NF ("NOFAIL 
module . 



Error traps through vector 
4 or 10 when system has been\_fc5L 
configured without NF ' 

("NOFAIL") module. 



STARTing CPU 
at address 52. 



:> 



Q 



_r\. 



HALT CPU 
(Address 54) 



STARTing CPU ^ 
at address 50 J 



J. 








Write Contents Of 
Core Onto CRASH. SYS 
■File. 



Write Contents Of Core 
Onto CRASH. SYS File. 





V 




Re-boot 


System 


From 


Disk an 


3 Begin 


Ex- 


ecuting 


The In: 


.tiali- 


zation 


C:ode. 





Resume Normal System 
Operations At Next Clock 
Or Device Interrupt. 
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APPENDIX G 
DECPACK DISTRIBUTION 

G.l RSTS-11 DECpack Kit and System Generati on Procedures 

The RSTS-11 DECpack software is distributed on two RK03/05 
DECpack disk cartridges. The contents of the supplied Generation 
DECpack are the same as the contents of DECtapes #0, #1, and the DOS 
Monitor of the RSTS-11 DECtape kit, except that the DOS Monitor is 
V08-02. The contents of the Library DECpack correspond identically 
to the contents of DECtape #2. (Refer to section 2.1 for a description 
of the contents of the DECtapes.) 

The generation of the RSTS-11 system using the DECpack distribution 
entails the following steps. The system manager should read the entire 
guide before attempting to follow these steps, which are described in 
sections G.2 through G.8. 

1. Activate the supplied DOS-11 V08-02 Monitor. 

2. Format two new DECpack cartridges using the DSKINT 
stand-alone program. 

3 Using the ROLLIN stand-alone program, copy the 
supplied Generation DECpack to one of. the newly 
formatted cartridges. The original distributed 
Generation DECpack is then stored in a safe place. 

4. Run the SYSGEN program, answer the SYSGEN _ questions , 
and follow the system generation instructions 
printed in the dialogue preview. 

5 After building the RSTS-11 CIL on the system disk, 
follow the REFRESH initialization procedures. 

6 The final steo consists of building the system 
library using che supplied Library DECpack and 
establishing the system accounts, text messages, 
and control files . 

7. copy the newly-created RSTS-11 system onto a backup 
cartridge. 



Boctir.a the DOS Monitor 



Mount the RSTS V4A-12 Generation DECpack (DEC-11-ORDPA-A-HCj on 
the RK03/05 drive unit 0. Write enable drive unit 0. Bootstrap the 
Monitor by doing the following: 



September 19 74 



Move the CPU's ENABLE/HALT switch to its HALT position. 

If the BM79 2-YB Hardware Loader is on the system: 

Set the CPU Switch Register to 17310$. 

Depress the CPU LOAD ADDRESS switch. 

Move the CPU ENABLE/HALT switch to its ENABLE position. 

Set the CPU Switch Register to 1774)2(6. 

Depress the CPU START switch. 

If the MR11-DB Hardware Loader is on the system: 

Set the CPU Switch Register to 173110. 

Depress the CPU LOAD ADDRESS switch. 

Move the CPU ENABLE/HALT switch to its ENABLE position.' 

Depress the CPU START switch. 

When the Monitor is loaded, it prints its header identification, 

followed on another line by a $ character which indicates that the 

system is ready to accept command strings. The printout appears as 

follows : 

DOS Vjg8-02 
$ 

If the message does, not appear, reset the CPU ENABLE/HALT switch to 
HALT and try again, checking carefully the values loaded into the 
registers . 

G. 3 Formatting the Cartridges 

Mount one of two new DECpack cartridges on RK03/J3 5 drive unit 1. 
Run CILUS and boot in the disk initializer program DSKINT by following 
the dialogue shown below: 

$RUN CILUS 

CILUS V11A69 

#DSKINT . CIL [1,1] /BOOT 



NOTE 

Messages printed by the system are 
indicated by underlining. Responses 
to be entered by the user must be 
terminated by pressing the RETURN 
key. The RETURN key is echoed by 
the performance of a line-feed/carriage 
return operation. 
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When the DSKINT program is loaded, the following header and 
query lines are printed. 

RSTS DISK INITIALIZER V4A-00 
DISK (RF, RK, RP) = 

At this point, remove the DECpack distribution cartridge from RK03/05 
drive unit and replace it with the second new DECpack cartridge. 
Consult section 6.2 of this manual for information on using the 
DSKINT program. The dialogue appears as follows: 

DISK (RF,RK,RP) = RK 

DRI V E MUM (RK, RP ) O R NUM PLATTERS-1 (RF) = 1 

DISK ID (UP TO 6 CHARS) = RSTS11 

PACK CLUSTER SIZE (1,2,4,8 OR 16) = 1 

MFD PASSWORD (UP TO 6 CHARS)' = V04A12 

MFD CLUSTER SIZE (AT LEAST=PACK CLUST) = 1 

PUBLIC (PUB) OR PRIVATE (PRI) = PUB 

PACK FORMAT T ING (Y OR N) = Y 

READY DISK THEN TYPE CR 



INITIALIZATION COMPLETE 



RSTS DISK INITIALIZER V4A- 



DISK (RF,RK,RP) 



When the initialization and formatting is completed, the program 
is reinitialized and prints the header and first query line. 

Repeat the same procedures for the second cartridge, but use 
DRIVE NUM = in the second question. Leave the first cartridge 
mounted when the initialization is completed, and replace the second 
cartridge in drive unit with the DECpack distribution cartridge, 
DEC-11-ORDPA-A-HC . 

G. 4 Copying the Distribution DECpack 

Boot the DOS Monitor into core again as described in section 
G.2. Run CILUS, boot ROLLIN into core and copy the supplied 
DECpack, which is mounted on drive unit 0, onto the newly formatted 
cartridge which remains mounted on drive unit 1. The dialogue -is 
as follows: 
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DOS V08-02 
$RUN CILUS 
CILUS V01A69 

_ruj.uuxrj . i^l-U i±,j.j/Du\jx 

ROLLIN V05A 

#DKl:<DKj3: 

i 

WARNING 

Be sure that the copy command is typed 
EXACTLY as shown before typing the 
RETURN key. Do NOT under any circumstances 
type a ">" character or type the unit 
numbers in reverse order. 

The completion of the copy operation is signalled by the printing of 
the # character. Upon completion of the copy operation, dismount 
the supplied DECpack from drive unit J3 and store it in a safe place. 
Transfer the copy from drive unit 1 to drive unit $. Write Enable unit jZf. 

G.5 Running the SYSGEN Program 

With the copy of the supplied DECpack mounted on unit J0, boot 
the DOS Monitor into core as shown, perform the login procedure, 
and run the SYSGEN program. 

#/BOOT:DK 
DOS V08-02 

$DATE dd-mon-yy [for example: 13-NOV-72] 

$TIME hh:mrr. [for example: 13:J3j3] 

$LOGIN 1,1 

DATE:-13-NOV-72 

TIME: -13:00:15 

$RUN SYSGEN 

RSTS-11 VIA SYSTEM GENERATION 

The date and time must be given in the format shown. When 
the SYSGEN program header is printed, answer the questions 
printed by SYSGEN. Refer to sections 2.2 and 2.3 of this guide 
for the complete explanation of the process. When all the questions 

are answered, the SYSGEN program prints (on the line printer or on 
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the console Teletype, as directed) a preview image of the subsequent 
system generation dialogue. Follow the instructions and use the exact 
command strings which SYS GEN has printed in the preview. When the 
last command indicated by the SYSGEN preview is executed, the RSTS-11 
CIL exists on the DECpack on drive unit 1. Dismount the cartridge from 
unit and transfer the cartridge just built on drive unit 1 to drive 
unit j3. Proceed to "Refreshing the System Disk" below. 

G.6 Refreshing the System Disk | 

Boot the newly-created RSTS-11 system into core by following the 
procedures described in section G.2. Next, refresh the system disk 
following the procedures described in sections 2.2.11 and 2.3.15. 
Perform the initialization as described in section 2.3.16. 

G.7 Building the System Library 

When the RSTS-11 Monitor has been initialized and prints the READY 
message, it will be necessary to mount the distributed Library DECpack 
and to build the system library by retrieving files from the Library 
DECpack and following procedures similar to those outlined in sections 
2.3.17 through 2.3.21. 

G.7.1 Mounting the Library DECpack 

After the system prints the READY message, mount the RSTS V4A-12 
Library DECpack (DEC-11-ORPTA-A-HA). on RK03/05 drive unit 1. Write 
enable drive unit 1. Type the following immediate mode statements: 

READY „ v 

X$ = SYS I CHR$(6) + CHRSC-10) + " DK1 : V4ALIB ) 

READY 

Y$ = RIGHT ( X$ , 4 .) 

READY ^ % 

Z$ = SYS( CHRSC6) + CHR$(3) + CHR$(j3) + Y$ ). 

READY 

The distribution Library DECpack will then be logically mounted, and 
files on .it may be accessed. 

G.7.2 Retrieving the Library Files 

When the Library DECpack has been logically mounted, as outlined 
above, follow the instructions in sections 2.3.17 through 2.3.21. 

Substitute DK1 : for the device designator DT0 : shown in the example 
command strings, since the system programs and text files exist on 
DECpack drive unit 1 rather than DECtape. Sample command lines are 
shown below: 

G-5 September 1974 



READY 

OLD DK1: LOGIN 

READY 

COMPILE 

READY 

OLD DK1: LOGOUT 

READY 

etc. . . 

When the system library has been built, the distributed Library DECpack 
may be removed by following instructions contained in section 5.3.2.1. 

G. 8 Preserving the RSTS-11 System 

When the RSTS-11 system has been generated, use the ROLLIN 
stand-alone program as described in section 6.1 to create a copy of 
the system on the other new DECpack cartridge. 
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INDEX 



Account numbers , system , 1-6 

Account regulation, 1-6 

Accounts, privileged, see Privileged 

accounts 
Accounts, user, 2-22, 5-19 
ACCT.SYS file, 2-22, 2-38, 5-23 
ANALYS system program, 5-35, 5-36 
ASR-33 type terminals, 5-31 
Asterisk t*) character, 5-7 
Automatic answering facility, 2-10, 

B-4 
Automatic recovery, 2-13, 3-9, 3-11 
Automatic restart, 3-3, 3-4, 3-7, 

3-12, 3-13,4-5 
flow chart, F-l 



.BAC file, 1-4 

Back-up system, 1-6 

Bad block checking, S -11 

Bad sectors, 2-19 

BAD. SYS file, 3-8 

.BAS file, 2-3 

Block count, 5-30 

BOOT option, 3-9 

Bootstrapping 

disk initializer program, G-3 

monitor, G-2 

RSTS from DECtape, 3-5 

RSTS from disk, 3-2 
BUFF. SYS file, 4-9 
Building operations DSKINT, 6-11 
Building overlays for LINK program, 

2-27 
Building the System Library, 2-20, 

2-21 
BYE command, 3-7, 5-6 



Cartridge - see disk 
Catastrophic errors, 3-9, 3-10, 3-12, 
5-29 

recovery code, 2-13 
CHAIN statement, 1-4 
CIL DECtape, 1-6, 2-16, 2-29 
Clock-related parameters, 2-9 
Cluster factors, 4-9 
Cluster size 

account, 2-23 

directory, 4-7 

MFD, 2-19 

pack, 2-13, 2-23, 4-7 

UFD, 5-28 
Command String Interpreter CCSI) ,2-1 
Comments, processing user, 5-37 
Compiled program, 1-4 
CONFIG system program, 2-40, 5-34 



Configuration, 1-5 

errors, 3-10 

file, 2-8, 2-9, 2-27 

options, 2-1 
Control files, 2-39, 5-4 
Conversion lowercase/uppercase, 2-10 
Copying RK11 cartridges, 6-10 
Core image, 1-3 

Core Image Library (CIL) , 2-14, 
2-16, 4-10 

generation, 2-3 
Core resident elements, 1-2 
CORE. SYS file, 3-2, 4-9,4-10 
CRASH. CTL system program, 2-39, 

3-13, 5-7 
Crash-dump facility, 2-20, 3-4, 3-12 
CRASH. SYS file, 2-17-, 3-4, 3-6, 3-8, 

3-13, 4-10, 5-29, 5-36 
CSI (Command String Interpreter) , 
2-1 



Data transfers, 1-5, 6-1 

DC11 default characteristics, 2-4 

DCll interfaces, 2-10 

DC11 line characteristics, 2-40 

DECpack kit, G-l 

copying , G-3 
DECtape, 6-4 

files, 2-3 through 2-6 

kit, 2-2 

processing, 4-9 
Default characteristics, DCll, 2-4 
Delete function, 5-22 

responses to queries, 5-22 
Deleting user accounts, 5-19 
Detached job status, 5-30 
Device-related parameters, assign- 
able, 2-11 
Device specifications, 6-2 
Dialogue "preview", 2-1, 2-14 
Dialogue, system generation, 2-9 
Disk cartridge initialization 
program, 2-14 

see also DSKINT 
Disk device in locked state, 5-15 
Disk file, temporary, 1-4 
Disk initializer program, boot- 
strapping, G-3 
Disk management, 5-14 
Disk packs, procedures for using, 

5-17 
Disk quota, 2-2 3 
Disk refreshing, 2-17, 3-7 
Disk-related parameters, 2-g 
Disk resident elements, 1-3 
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Disk storage 

initialization and formatting, 6-1 

quota, 5-16 
Disk structures, private, 1-4 
Disk to DECtape dump, 6-5 
Disk to magtape dump, 6-6, 6-7 
Distribution 

DECpack kit, G-l 

DECtape kit, 2-2 
DOC filename extensions, 2-3, 5-1 
Dollar C$) character, 5-3, G-2 
DOS-11 software 2-8 
DOS Monitor 

files, 2-2 

loading, 2-25 
DSKINT, 2-30, 3-8, 6-1, 6-11 



Edit mode, 1-4 
ENTER function, 5-19 

responses to queries, 5-21 
Error message file (ERRM.SYS), 2-18, 

3-8 
Error messages, 2—1 

DOS-11, D-l 

initialization, E-l 

ROLLIN, 6-10 
Errors 

catastrophic , 2-13, 3-9 , 3-12 ,5-29 

in dialogue queries, 6-12 

in formatting operations, 6-12 

in initialization operations, 6-13 

on disk, 6-13 
Error trap, 3-9, 3-10 
Execution times by disk type, 6-14 
Exponentiation, 7-4 



Failure of system software, 2-17 

Filename extensions, 2-3 

File protection, 1-6, 2-13 

Files, DECtape, 2-3 through 2-6 

Fill character, B-2 

File access, unlimited, 4-11 

File cluster size, 5-28 

File contents, system library, 4-6 

FIP code, 4-15 

FIP system function, 4-16 through 

4-24 
FNEND, 7-1 
FORCE command, 5-5 
Format operations DSKINT, 6-11 
Formatting of print lines, 2-13 
FREE block count, 5-30 
Functions, mathematical, 2-12 



Generalized fill, B-2 



Halt procedures, RSTS-11, 3-1 
Hardware 

configuration, 1-5 

malfunction, 3-10 
HB (hibernate ) state, 5-30 
HELP. TXT file, 2-22, 4-5 



IF. . .THEN. . .ELSE statement, 7-2 
Image-mode copies , 1-6 
Immediate mode statement, 1-4 
Initialization 

CIL routine, 2-17 

disk storage, 6-1 

error messages, E-l 

normal, 2-3 3 

RSTS-11, 2-20, 2-32, 3-4 

software structures on system 
disk, 2-17 
INIT system program, 2-39, 3-13, 5-2 

control files, 2-23, 2-24 
INPUT #, 7-1 
INPUT statements, 7-1 
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Intermediate code, 1-4 

Intermediate file preservation, 2-16, 

2-3 
Interrupt, user, 1-4 
I/O handlers, 1-5 



Job status information, 2-12 



KEll-A EAE element, 2-12 

Keyboard dialogue, 2-9 

Keyboard, freeing With BYE command, 

5-6 
Keyboard numbers, assignment of, 5-3 4 
Keyboard malfunction, 5-29 



Label block, 6-4 
.LDA file, 2-3 
Levels of software, 1-2 
Library, system, 5-1 

file contents , 4-6 
Line printer listings, 2-14 
Line printer modification, 2-11 
LINK program overlays, 2-27 

linking, 2-28 
Loading, 2-31 

core image library (CIL), 2-17,2-31 

DOS Monitor, 2-25 

Monitor with DECpack, G-2 

SYSLOAD, 2-2 4 
Load map, 2-16 

printing, 2-29 
LOAD option, 3-8 
Locked state of disk device, 5-15 
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Logging in, 2-16 
LOGINS command, 5-5 
LOGIN system program, 4-1 



.MAC file, 2-3 
Magtape format, ROLLIN, 6-8 
Malfunctioning Keyboards, 5-29 
Mass-storage transfer program, 2-14 
Master file directory (MFD) account, 
4-1, 4-3 

cluster size, 2-19 

on non-system device, 4-2 
Math packages, 2-12 
Matrix operations code, 2-13 
MAT statement, 7-1 
Maximum job number, 2-12 
Message files, standard, 2-22 
MFD account 

see Master file directory 
Modes , 

Edit, 1-4 

run, 1-4 
MONEY system program, 1-6, 5-24, 5-26 

options, 5-25 

output, 5-27 
Monitoring system status (SYSTAT) , 

5-28 
MOUNT command, 5-5, 5-14 
Mounting the disk, 4-4, 5-14 
Multiple users, 2-13 

Name of installation, 2-9 
No-Fail module, 3-11 
Normal system startup, 3-5, 5-3 
NOTICE.TXT file, 2-22 4-5, 5-10 
Null fill characters, 2-10 B-3 



.OBJ file, 2-3 

Operational control of system, 5-17 
Options, RSTS initialization, 3-5 
Orderly halt, 3-1 
Output parity bit, B-4 
Overlay files DOS-11 program, 2-14, 
2-18 

assemblies, 2-14, 2-15 

linking, 2-15 

symbol table file, 2-15 
OVER. SYS file, 3-8, 4-9 



Pack cluster size, 2-18, 4-7 
Pack identification name, 2-18, 4-4 
Pack label information, 4-4 
Parity generation, 2-10 
Passwords, 1-6, 2-19, 4-1, 5-16 
PDP-11/45 system 

generation, 2-8 

requirements, 2-2 



PEEK function, 4-24 

PIP system program, 5-3, 5-24 

PIP. TXT file, 4-5 

Pound (#) character, 6-1 

Power fail code, 

Primary system software elements, 

1^2, 2-3, 2-7, 2-35 
Print Using software, 2-13 
PRINT USING statement, 7-3 
Private ■ disk structures, 1-4, 4-2 
Private packs, 1-4 

Privileged access accounts, 1-6,4-10 
Privileged programs, 

creation and modification, 4-11 

status, 1-3 
Program documentation, 2-3 
Programming errors, privileged 

account, 3-10 
Programs, system library, 2-20 
Program statement, 1-4 
Project-programmer number, 4-1 
Protection violation, 4-11 
Public disk structure, 1-3, 4-2 



Radix -50 conversion, 4-17 
REACT system program, 1-6,2-22,2-38, 
5-19 
functions, 5-20 
Record I/O software, 2-13 
Recovery procedures, 3-1 
Refreshing system disk, 2-17, G-5 
2-32 

REFRESH option, 2-17 

Remote line characteristics, 5-31, 

5-34 
Remote reader control, B-3 
Remote terminal, B-3 
Removing disk pack, 5-15 
Restart procedures, 3-1 

after system crash, 5-7 
Restoring disk 

from DECtape, 6-5 

from Magtape, 6-9 
ROLLIN program, 1-6, 2-14, 2-30. 
3-4, 3-8, 6-1 

editing commands, 6-4 

option switch descriptions, 6-3, 
6-4 
Round-robin scanning, 1-5 
RUBOUT key, 6-4 
RUN command, 1-4 
Run mode, 1-4 
Run time system, 1-4 



SAT see Storage Allocation Table 
Secondary system software elements, 

1-2, 1-3, 2-3 
Shutdown of system, 5-8, 5-9 
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SHOTUP program, 3-1, 3-3 
Small buffers, 2-12 
Software 

configuration, 1-5 

deficiencies, 3-11 

distribution, 2-2 

optional features, 2-13 
Source material, 2-3 
Stand-alone programs, 6-1 
STANDARD function, 5-23 
START. CTL file, 2-23, 2-24, 2-39, 3-7 

5-3 
Start procedures, RSTS-11, 3-1, 3-2, 

3-5, 4-5 
Startup mode, 3-3 

Status information, active job, 2-12 
Storage space, disk, 5-7 
Storage Allocation Table (SAT) ,4-7 

rebuilding; 5-15 
Structures, private disk, 1-4 
SURE? question, 3-8 
Swapping device , 1-3 
SWAP. SYS file, 1-5, 2-12, 4-9 
SYS. file, 2-3 

function, 1-3, 1-6, 

system function calls to FIP, 4-15 
SYSGEN, 2-6, G-4 

interrogation summary, A-l 

procedures, 2-1 
SYSLOD error halts, C-i 
SYSLOD, loading, 2-24 
SYSTAT system program, 5-28 
System 

access, 4-1 

accounts, 1-6, 2-38, 4-1, 4-7 
contents, 4-8 
on non-system disks, 4-10 

accounting operations (MONEY), 5-24 

back-up, 1-6, 2-24 

command, 1-4 

crash, 3-9, 3-10, 3-11, 5-35 

disk, 1-3 

disk refreshing, 2-32, G-5 

documentation, 2-16 

errors, 2-13 

function formats and codes, 4-13 
through 4-24 

generation, 1-5, 2-6, 2-24 
with DECpack, G-l , G-4 
with DECtape, 2-2 

initialization, normal, 2-33 

library, 1-3,' 2-20, 2-21, 2-34,5-1 

library account, 4-4 

library, building, G-5 

library file contents, 4-6 

library message files, 2-22 

library password and cluster size, 
2-19 

load map, 2-29 

message files, 2-38 



System (Cont.) 

Monitor update tape, 2-26 
operational control, 5-17 
preserving RSTS-11, G-5 
restart after crash, 5-7 
scheduler, 1-5 
shutdown, 5-8, 5-9 
software failure, 2-17 
startup - normal, 4-5 
startup via INIT, 5-2 
utility operation, 5-10 



Target string, 4-16 
Temporary disk file, 1-4 
Terminal characteristics, 5-31 

automatic setting, 5-33 
Terminal related parameters, 2-10 
Terminating DSKINT, 6-12 
Time sharing, 5-5 
Trap, 3-11 
TTYSET system program, 5-5, 5-31, 

5-32 
•TXT file, 2-3 



UFD cluster size, 5-2 8 

Unlimited file access, 4-11 

Update feature, 2-13 

Upper and lower case characters,B-2 

User accounts, 2-22 

creating and deleting, 5-19 
User comments, processing, 5-3 7 
User job area, 1-4 
User jobs, 1-5 

UTILTY system program, 1-6, 5-1, 
5-10, 5-17 

commands, 5-12, 5-13 



ZERO command (UTILTY) , 5-16 
Zeroing 

a DECtape, 2-16 
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HOW TO OBTAIN SOFTWARE INFORMATION 

SOFTWARE NEWSLETTERS, MAILING LIST 

The Software Communications Group, located at corporate headquarters in 
Maynard, publishes software newsletters for the various DIGITAL products. 
Newsletters are published monthly, and keep the user informed about cus- 
tomer software problems and solutions, new software products, documenta- 
tion corrections, as well as programming notes and techniques. 

There are two similar levels of service: 

The Software Dispatch 
The Digital Software News 

The Software Dispatch is part of the Software Maintenance Service. This 
service applies to the following software products: 

PDP-9/15 
RSX-11D 
DOS /BATCH 
RSTS/E 
DECsystem-10 

A Digital Software News for the PDP-11 and a Digital Software News for 
the PDP-8/12 are available to any customer who has purchased PDP-11 or 
PDP-8/12 software. 

A collection of existing problems and solutions for a given software 
system is published periodically. A customer receives this publication 
with his initial software kit with the delivery of his system. This 
collection would be either a Software Dispatch Review or Software Per- 
formance Summary depending on the system ordered. 

A mailing list of users who receive software newsletters is also main- 
tained by Software Communications. Users must sign-up for the news- 
letter they desire. This can be done by either completing the form sup- 
plied with the Review or Summary or by writing to: 

Software Communications 

P.O. Box F 

Maynard, Massachusetts 01754 

SOFTWARE PROBLEMS 

Questions or problems relating to DIGITAL'S software should be reported 
as follows: 

North and South American Submitters : 



Upon completion of Software Performance Report (SPR) form remove last 
copy and send remainder to: 

Software Communications 

P.O. Box F 

Maynard, Massachusetts 01754 

The acknowledgement copy will be returned along with a blank SPR form 
upon receipt. The acknowledgement will contain a DIGITAL assigned SPR 
number. The SPR number or the preprinted number should be referenced in 
any future correspondence. Additional SPR forms may be obtained from 
the above address. 

All International Submitters : 

Upon completion of the SPR form, reserve the last copy and send the re- 
mainder to the SPR Center in the nearest DIGITAL office. SPR forms are 
also available from our SPR Centers. 

PROGRAMS AND MANUALS 

Software and manuals should be ordered by title and order number. In the 
United States, send orders to the nearest distribution center. 



Digital Equipment Corporation 
Software Distribution Center 
146 Main Street 
Maynard, Massachusetts 01754 



Digital Equipment Corporation 
Software Distribution Center 
1400 Terra Bella 
Mountain View, California 94043 



Outside of the United States, orders should be directed to the nearest 
Digital Field Sales Office or representative. 

USERS SOCIETY 

DECUS, Digital Equipment Computers Users Society,- maintains a user ex- 
change center for user-written programs and technical application infor- 
mation. The Library contains approximately 1,900 programs for all 
DIGITAL computer lines. Executive routines, editors, debuggers, special 
functions, games, maintenance and various other classes of programs are 
available. 

DECUS Program Library Catalogs are routinely updated and contain lists 
and abstracts of all programs according to computer line : 

PDP-8, FOCAL-8, BASIC-8, PDP-12 
PDP-7/9, 9, 15 
PDP-11, RSTS-11 
PDP-6/10, 10 

Forms and information on acquiring and submitting programs to the DECUS 
Library may be obtained from the DECUS office. 

In addition to the catalogs., DECUS also publishes the following: 

DECUSCOPE -The Society's technical newsletter, published bi-monthly, 

aimed at facilitating the interchange of technical in- 
formation among users of DIGITAL computers and at dis- 
seminating news items concerning the Society. Circula- 
tion reached 19,000 in May, 1974. 



PROCEEDINGS OF 
THE DIGITAL 
EQUIPMENT USERS 
SOCIETY 

MINUTES OF THE 

DECsystem-10 

SESSIONS 

COPY-N-Mail 

LUG/SIG 



-Contains technical papers presented at DECUS Symposia 
held twice a year in the United States, once a year 
in Europe, Australia, and Canada. 

-A report of the DECsystem-10 sessions held at the two 
United States DECUS Symposia. 

-A monthly mailed communique among DECsystem-10 users. 
-Mailing of Local User Group (LUG) and Special Interest 



Group (SIG) communique, aimed at providing closer 
communication among users of a specific product or 

application. 

Further information on the DECUS Library, publications, and other DECUS 
activities is available from the DECUS offices listed below: 



DECUS 

Digital Equipment Corporation 

146 Main Street 

Maynard, Massachusetts 01754 



DECUS EUROPE 

Digital Equipment Corp. 

(Europe) 

P.O. Box 340 

1211 Geneva 26 

Switzerland 
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Announcements for new and revised software, as well as programming notes, software problems, 
and documentation corrections are published by Software Information Service in the following 
newsletters. 



Digital Software News for the PDP-8 and PDP-I2 
Digital Software News for the PDP-11 
Digital Software News for 18-bit Computers 



These newsletters contain information applicable to software available from Digital's Software 
Distribution Center. Articles in Digital Software News update the cumulative Software Per- 
formance Summary which is contained in each basic kit of system software for new computers. To 
assure that the monthly Digital Software News is sent to the appropriate software contract at your 
installation, please check with the Software Specialist or Sales Engineer at your nearest Digital 
office. 

Questions or problems concerning Digital's software should be reported to the Software Specialist. 
Incases where no Software Specialist is available, please send a Software Performance Report 
form with details of the problems to: 

Digital Equipment Corporation 
Software Information Service 
Programming Department 
Maynard, Massachusetts 01754 

These forms, which are provided in the software kit, should be fully filled out and accompanied 
by Teletype output as well as listings or tapes of the user program to facilitate a complete inves- 
tigation. An answer will be sent to the individual and appropriate topics ofgeneral in- 
terest will be printed in the newsletter. 

Orders for new and revised software manuals, additional Software Performance Report forms, and 
software price lists should be directed to the nearest Digital Field office or representative. USA 
customers may order directly from the Software Distribution Center in Maynard. When ordering, 
include the code number ond a brief description of the software requested. 

Digital Equipment Computer Users Society (DECUS) maintains a user library and publishes a cata- 
log of programs as well as the DECUSCOPE magazine for its members and non-members who request 
it. For further information, please write to: 

Digital Equipment Corporation 

DECUS 

Programming Department 

Maynard, Massachusetts 01754 
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